[Dri-devel] mga cvs changes
I've just commited a lot of stuff to the mga driver. The cvs commit messages bounced so I've attached them to this message if someone wants to look at them :) -- Ville Syrjälä [EMAIL PROTECTED] http://www.sci.fi/~syrjala/ --- Begin Message --- This message was created automatically by mail delivery software. A message that you sent could not be delivered to one or more of its recipients. This is a permanent error. The following address(es) failed: [EMAIL PROTECTED] SMTP error from remote mailer after HELO pdx: host mail.sourceforge.net [66.35.250.206]: 550 Don't like your HELO/EHLO. Hostname must contain a dot. -- This is a copy of the message, including all the headers. -- Return-path: <[EMAIL PROTECTED]> Received: from syrjala by pdx with local (Exim 4.22) id 1AJRbV-0001zI-C6 for [EMAIL PROTECTED]; Mon, 10 Nov 2003 22:02:17 -0800 From: Ville Syrjala <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Subject: CVS Update: xc (branch: trunk) X-CVS-Notice: This email was automatically generated by a CVS checkin X-CVS-Problems: Send problems to [EMAIL PROTECTED] X-CVS-Version: Concurrent Versions System (CVS) 1.12.1 (client/server) X-CVS-Host: pdx running Linux 2.4.21 Message-Id: <[EMAIL PROTECTED]> Sender: Ville Syrjala <[EMAIL PROTECTED]> Date: Mon, 10 Nov 2003 22:02:17 -0800 CVSROOT:/cvs/dri Module name:xc Repository: xc/xc/lib/GL/mesa/src/drv/mga/ Changes by: [EMAIL PROTECTED] 03/11/10 22:02:17 Log message: Fixed GL_NV_texture_rectangle support. Modified files: xc/xc/lib/GL/mesa/src/drv/mga/: mga_texstate.c Revision ChangesPath 1.14 +7 -2 xc/xc/lib/GL/mesa/src/drv/mga/mga_texstate.c --- End Message --- --- Begin Message --- This message was created automatically by mail delivery software. A message that you sent could not be delivered to one or more of its recipients. This is a permanent error. The following address(es) failed: [EMAIL PROTECTED] SMTP error from remote mailer after HELO pdx: host mail.sourceforge.net [66.35.250.206]: 550 Don't like your HELO/EHLO. Hostname must contain a dot. -- This is a copy of the message, including all the headers. -- Return-path: <[EMAIL PROTECTED]> Received: from syrjala by pdx with local (Exim 4.22) id 1AJSx9-0002JV-6N for [EMAIL PROTECTED]; Mon, 10 Nov 2003 23:28:43 -0800 From: Ville Syrjala <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Subject: CVS Update: xc (branch: trunk) X-CVS-Notice: This email was automatically generated by a CVS checkin X-CVS-Problems: Send problems to [EMAIL PROTECTED] X-CVS-Version: Concurrent Versions System (CVS) 1.12.1 (client/server) X-CVS-Host: pdx running Linux 2.4.21 Message-Id: <[EMAIL PROTECTED]> Sender: Ville Syrjala <[EMAIL PROTECTED]> Date: Mon, 10 Nov 2003 23:28:43 -0800 CVSROOT:/cvs/dri Module name:xc Repository: xc/xc/lib/GL/mesa/src/drv/mga/ Changes by: [EMAIL PROTECTED] 03/11/10 23:28:43 Log message: State cleanups: - FLUSH_BATCH() + dirty -> MGA_STATECHANGE() - Use MGA_FIELD() macro - mgaDDEnable() forgot to set MGA_UPLOAD_CONTEXT in some cases - Avoid setting the same bits in multiple places Modified files: xc/xc/lib/GL/mesa/src/drv/mga/: mgastate.c Revision ChangesPath 1.49 +40 -51xc/xc/lib/GL/mesa/src/drv/mga/mgastate.c --- End Message --- --- Begin Message --- This message was created automatically by mail delivery software. A message that you sent could not be delivered to one or more of its recipients. This is a permanent error. The following address(es) failed: [EMAIL PROTECTED] SMTP error from remote mailer after HELO pdx: host mail.sourceforge.net [66.35.250.206]: 550 Don't like your HELO/EHLO. Hostname must contain a dot. -- This is a copy of the message, including all the headers. -- Return-path: <[EMAIL PROTECTED]> Received: from syrjala by pdx with local (Exim 4.22) id 1AJT0R-0002LH-IA for [EMAIL PROTECTED]; Mon, 10 Nov 2003 23:32:07 -0800 From: Ville Syrjala <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Subject: CVS Update: xc (branch: trunk) X-CVS-Notice: This email was automatically generated by a CVS checkin X-CVS-Problems: Send problems to [EMAIL PROTECTED] X-CVS-Version: Concurrent Versions System (CVS) 1.12.1 (client/server) X-CVS-Host: pdx running Linux 2.4.21 Message-Id: <[EMAIL PROTECTED]> Sender: Ville Syrjala <[EMAIL PROTECTED]> Date: Mon, 10 Nov 2003 23:32:07 -0800 CVSROOT:/cvs/dri Module name:xc Repository: xc/xc/lib/GL/mesa/src/drv/mga/ Changes by: [EMAIL PROTECTED] 03/11/10 23:32:07 Log message: Wrapped logic op fallbacks inside ACCEL_ROP. Modified files: xc/xc/lib/GL/mesa/src/drv/mga/: mgastate.c Revision ChangesPath 1.50 +4 -0 xc/xc/lib/GL/mesa/src/drv/mga/mgastate.c --- En
Re: [Dri-devel] mga cvs changes
Ville Syrjälä wrote: I've just commited a lot of stuff to the mga driver. The cvs commit messages bounced so I've attached them to this message if someone wants to look at them :) Looks like some good cleanups & other nice work... Keith --- This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas. Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! http://www.apachecon.com/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mga cvs changes
Ville Syrjälä wrote: I must say that I am very impressed with how far the MGA driver has come since you started working on it. Now the only thing that's missing is support for PCI cards. ;) Log message: Fixed GL_NV_texture_rectangle support. Any idea how tough it will be (or if it's possible!) to add support for ARB_texture_non_power_of_two? Bascially, it just extends the regular texture modes to not require textures be a power of two. Mipmapping and all the wrap modes are still supported, and texture coordinates are still speicified as [0,1] (as opposed to [0,size] as in NV_texture_rectangle). I suspect the hardware won't support it. http://oss.sgi.com/projects/ogl-sample/registry/ARB/texture_non_power_of_two.txt Log message: Texure environment updates: - Each texture unit has it's own environment color but we have only one FCOL register. - Move GL_BLEND handling to a separate function. - Remove unnecessary memcpy of TexState[0] to TexState[1]. The kernel will not upload tex1 unless a dualtex warp pipe is used. I see to recall that an older version of the DRM did not behave that way, and that's why the copy was there. That would have been a long time ago (more than 18 months), so I don't think we need to support that. However, the driver should refuse to load on that version of the DRM. Without looking back through logs and diff, I don't know what version that would have been. I don't think this is /that/ important, but it might bite somebody sometime, and when it does it will take one of us a long time to debug. --- This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas. Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! http://www.apachecon.com/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mga cvs changes
On Tue, Nov 11, 2003 at 10:50:01AM -0800, Ian Romanick wrote: > Ville Syrjälä wrote: > > I must say that I am very impressed with how far the MGA driver has come > since you started working on it. Now the only thing that's missing is > support for PCI cards. ;) A quick fix would be simply enabling PCI cards but keep the agpgart restriction. The only change required would be changing the access type to PCI in the DMA registers. I think it should work but I don't have a PCI card to test with so I can't be 100% sure. > > Log message: > > Fixed GL_NV_texture_rectangle support. > > Any idea how tough it will be (or if it's possible!) to add support for > ARB_texture_non_power_of_two? Bascially, it just extends the regular > texture modes to not require textures be a power of two. Mipmapping and > all the wrap modes are still supported, and texture coordinates are > still speicified as [0,1] (as opposed to [0,size] as in > NV_texture_rectangle). I suspect the hardware won't support it. The G400 specs say that no mipmapping and clamp only. Which are exactly the same restrictions that NV_texture_rectangle specifies. > > Log message: > > Texure environment updates: > > - Each texture unit has it's own environment color but we have only one > > FCOL register. > > - Move GL_BLEND handling to a separate function. > > - Remove unnecessary memcpy of TexState[0] to TexState[1]. The kernel > > will not upload tex1 unless a dualtex warp pipe is used. > > I see to recall that an older version of the DRM did not behave that > way, and that's why the copy was there. That would have been a long > time ago (more than 18 months), so I don't think we need to support > that. However, the driver should refuse to load on that version of the > DRM. Without looking back through logs and diff, I don't know what > version that would have been. I don't think this is /that/ important, > but it might bite somebody sometime, and when it does it will take one > of us a long time to debug. I did look at the cvs logs and I think this stuff was there before XFree86 4.0. Isn't the pre 4.0 drm already incompatible with the current stuff? -- Ville Syrjälä [EMAIL PROTECTED] http://www.sci.fi/~syrjala/ --- This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas. Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! http://www.apachecon.com/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mga cvs changes
--- Ville_Syrj�l� <[EMAIL PROTECTED]> wrote: > On Tue, Nov 11, 2003 at 10:50:01AM -0800, Ian Romanick wrote: > > Ville Syrj�l� wrote: > > > > I must say that I am very impressed with how far the MGA driver has > come > > since you started working on it. Now the only thing that's missing > is > > support for PCI cards. ;) > > A quick fix would be simply enabling PCI cards but keep the agpgart > restriction. The only change required would be changing the access > type to > PCI in the DMA registers. I think it should work but I don't have a > PCI > card to test with so I can't be 100% sure. > There was a webpage with code for G450 PCI support but the author seems to be incommunicato. I haven't really looked at the changes. I don't know how different it would be from g200 PCI cards. > > > Log message: > > > Fixed GL_NV_texture_rectangle support. > > > > Any idea how tough it will be (or if it's possible!) to add support > for > > ARB_texture_non_power_of_two? Bascially, it just extends the > regular > > texture modes to not require textures be a power of two. > Mipmapping and > > all the wrap modes are still supported, and texture coordinates are > > > still speicified as [0,1] (as opposed to [0,size] as in > > NV_texture_rectangle). I suspect the hardware won't support it. > > The G400 specs say that no mipmapping and clamp only. Which are > exactly > the same restrictions that NV_texture_rectangle specifies. You might be able to get the EXT_texture_rectangle, looks similar to the NV version. > > > > Log message: > > > Texure environment updates: > > > - Each texture unit has it's own environment color but we have > only one > > > FCOL register. > > > - Move GL_BLEND handling to a separate function. > > > - Remove unnecessary memcpy of TexState[0] to TexState[1]. The > kernel > > > will not upload tex1 unless a dualtex warp pipe is used. > > > > I see to recall that an older version of the DRM did not behave > that > > way, and that's why the copy was there. That would have been a > long > > time ago (more than 18 months), so I don't think we need to support > > > that. However, the driver should refuse to load on that version of > the > > DRM. Without looking back through logs and diff, I don't know what > > > version that would have been. I don't think this is /that/ > important, > > but it might bite somebody sometime, and when it does it will take > one > > of us a long time to debug. > > I did look at the cvs logs and I think this stuff was there before > XFree86 > 4.0. Isn't the pre 4.0 drm already incompatible with the current > stuff? > the breakage was between 4.0 and 4.1, so I wouldn't worry about anything older than 4.1. Alex __ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree --- This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas. Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! http://www.apachecon.com/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mga cvs changes
On Tue, Nov 11, 2003 at 10:50:01AM -0800, Ian Romanick wrote: > Ville Syrjälä wrote: > > - Remove unnecessary memcpy of TexState[0] to TexState[1]. The kernel > > will not upload tex1 unless a dualtex warp pipe is used. > > I see to recall that an older version of the DRM did not behave that > way, and that's why the copy was there. That would have been a long > time ago (more than 18 months), This change was done on Feb 12 2000: http://cvs.sourceforge.net/viewcvs.py/dri/xc/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/Attic/mga_state.c?r1=1.1.2.8&r2=1.1.2.9 So it predates even XFree86 4.0 :) -- Ville Syrjälä [EMAIL PROTECTED] http://www.sci.fi/~syrjala/ --- This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas. Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! http://www.apachecon.com/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mga cvs changes
On Tue, Nov 11, 2003 at 11:31:59AM -0800, Alex Deucher wrote: > > The G400 specs say that no mipmapping and clamp only. Which are > > exactly > > the same restrictions that NV_texture_rectangle specifies. > > You might be able to get the EXT_texture_rectangle, looks similar to > the NV version. >From the looks of it it's the same extension. -- Ville Syrjälä [EMAIL PROTECTED] http://www.sci.fi/~syrjala/ --- This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas. Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! http://www.apachecon.com/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mga cvs changes
Alex Deucher wrote: You might be able to get the EXT_texture_rectangle, looks similar to the NV version. It's just another name for the same extension. I did look at the cvs logs and I think this stuff was there before XFree86 4.0. Isn't the pre 4.0 drm already incompatible with the current stuff? the breakage was between 4.0 and 4.1, so I wouldn't worry about anything older than 4.1. That's when the total DRM breakage happened. But when was the problem fixed in the MGA DRM where it read/set the texture control values for both texture units when only 1 was active? That's the issue I'm currently worried about. I know it was quite some time ago, but it doesn't seem like it was pre-4.1. It may have been, though. --- This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas. Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! http://www.apachecon.com/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mga cvs changes
Ville Syrjälä wrote: On Tue, Nov 11, 2003 at 10:50:01AM -0800, Ian Romanick wrote: Ville Syrjälä wrote: - Remove unnecessary memcpy of TexState[0] to TexState[1]. The kernel will not upload tex1 unless a dualtex warp pipe is used. I see to recall that an older version of the DRM did not behave that way, and that's why the copy was there. That would have been a long time ago (more than 18 months), This change was done on Feb 12 2000: http://cvs.sourceforge.net/viewcvs.py/dri/xc/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/Attic/mga_state.c?r1=1.1.2.8&r2=1.1.2.9 So it predates even XFree86 4.0 :) Okay. Well nevermind then. :) --- This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas. Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! http://www.apachecon.com/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mga cvs changes
On Tue, Nov 11, 2003 at 10:50:01AM -0800, Ian Romanick wrote: > Any idea how tough it will be (or if it's possible!) to add support for > ARB_texture_non_power_of_two? Bascially, it just extends the regular > texture modes to not require textures be a power of two. Mipmapping and > all the wrap modes are still supported, and texture coordinates are > still speicified as [0,1] (as opposed to [0,size] as in > NV_texture_rectangle). I suspect the hardware won't support it. I just noticed that this (marketing) document http://www.matrox.com/mga/products/tech_info/pdfs/g400/chip_specs.pdf claims that G400 support npot mipmapping. And considering that the register specs are somewhat confusing and incorrect wrt mipmapping I wouldn't be surprised if it's true. Time to do testing but the extension is only supported in Mesa-newtree. Unfortunaately Mesa-newtree isn't ready for DirectFBGL so I think I'll take the easier route and port the extension to Mesa 5.0... -- Ville Syrjälä [EMAIL PROTECTED] http://www.sci.fi/~syrjala/ --- This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas. Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! http://www.apachecon.com/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mga cvs changes
On Fri, Nov 14, 2003 at 10:33:07AM +0200, Ville Syrjälä wrote: > On Tue, Nov 11, 2003 at 10:50:01AM -0800, Ian Romanick wrote: > > Any idea how tough it will be (or if it's possible!) to add support for > > ARB_texture_non_power_of_two? Bascially, it just extends the regular > > texture modes to not require textures be a power of two. Mipmapping and > > all the wrap modes are still supported, and texture coordinates are > > still speicified as [0,1] (as opposed to [0,size] as in > > NV_texture_rectangle). I suspect the hardware won't support it. > > I just noticed that this (marketing) document > http://www.matrox.com/mga/products/tech_info/pdfs/g400/chip_specs.pdf > claims that G400 support npot mipmapping. And considering that the > register specs are somewhat confusing and incorrect wrt mipmapping I > wouldn't be surprised if it's true. > > Time to do testing but the extension is only supported in Mesa-newtree. > Unfortunaately Mesa-newtree isn't ready for DirectFBGL so I think I'll > take the easier route and port the extension to Mesa 5.0... Test failed :( The WARP microcode seems to be somewhat picky about texture size because even non-mipmapped texture with GL_CLAMP comes out with wrong coordinates. And GL_REPEAT produces total crap. So I didn't even bother to check if npot mipmapping actually works... -- Ville Syrjälä [EMAIL PROTECTED] http://www.sci.fi/~syrjala/ --- This SF. Net email is sponsored by: GoToMyPC GoToMyPC is the fast, easy and secure way to access your computer from any Web browser or wireless device. Click here to Try it Free! https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
PCI MGA support (was Re: [Dri-devel] mga cvs changes)
Ville Syrjälä wrote: On Tue, Nov 11, 2003 at 10:50:01AM -0800, Ian Romanick wrote: I must say that I am very impressed with how far the MGA driver has come since you started working on it. Now the only thing that's missing is support for PCI cards. ;) A quick fix would be simply enabling PCI cards but keep the agpgart restriction. The only change required would be changing the access type to PCI in the DMA registers. I think it should work but I don't have a PCI card to test with so I can't be 100% sure. So, I've now been tasked to actually do this. I get to enable support for a G450 PCI card that IBM ships in some of its POWER based systems. So, not only is it PCI & PPC64, but there is *no* AGP available at all. I haven't started actually changing any code as I don't have the hardware yet, but it's on the way. I want to initially support this by just "disabling" AGP texturing. I looked in the DRI driver, and it looks like this can be done with some trivial changes in mga_xmesa.c. Basically, the code just needs to handle the case where serverInfo->agpTextureSize is 0. The DDX driver needs to be modified to detect PCI cards and do something smart there. I haven't looked in that code yet, but I'm guess it should be pretty trivial. Then comes the kernel. :( I started looking that the ILOAD code in mga_state.c. Basically, it looks like everything assume the source buffers are in AGP space. I'm guessing that I could just look at the flags field in the drm_device_dma structure and only set the MGA_SRCACC_AGP bit if _DRM_DMA_USE_AGP bit is set. Is _DRM_DMA_USE_SG *always* set for PCI DMA transfers? I don't want to exclude the possability of sourcing vertex data from on-card memory in the future. In the DRM, if there's no AGP available, then PCI memory has to be used for DMA. It looks like the setup for that happens in the DDX driver in MGADRIAgpInit (in mga_dri.c). In looking at that routine, it's not immediatly clear what to do. Obviously, DRM_AGP wouldn't be passed to any of the drmAddMap calls. Looking at radeon_dri.c, it looks like RADEONPciInit is the same as RADEONDRIAgpInit except it uses DRM_SCATTER_GATHER instead of DRM_AGP and drmScatterGatherAlloc instead of drmAgpAcquire / drmAgpAlloc / drmAgpBind. Is that right? MGADRIPciInit wouldn't be a complete duplication of MGADRIAgpInit because I don't intend to (initially) support PCIGART. Even when PCIGART is supported, not all chips in the MGA family support it. Is the PCI G450 the only one? --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id70&alloc_id638&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: PCI MGA support (was Re: [Dri-devel] mga cvs changes)
--- Ian Romanick <[EMAIL PROTECTED]> wrote: > Ville Syrjälä wrote: > > On Tue, Nov 11, 2003 at 10:50:01AM -0800, Ian Romanick wrote: > > > >>I must say that I am very impressed with how far the MGA driver has > come > >>since you started working on it. Now the only thing that's missing > is > >>support for PCI cards. ;) > > > > A quick fix would be simply enabling PCI cards but keep the agpgart > > restriction. The only change required would be changing the access > type to > > PCI in the DMA registers. I think it should work but I don't have a > PCI > > card to test with so I can't be 100% sure. > > So, I've now been tasked to actually do this. I get to enable > support > for a G450 PCI card that IBM ships in some of its POWER based > systems. > So, not only is it PCI & PPC64, but there is *no* AGP available at > all. > I haven't started actually changing any code as I don't have the > hardware yet, but it's on the way. > > I want to initially support this by just "disabling" AGP texturing. > I > looked in the DRI driver, and it looks like this can be done with > some > trivial changes in mga_xmesa.c. Basically, the code just needs to > handle the case where serverInfo->agpTextureSize is 0. The DDX > driver > needs to be modified to detect PCI cards and do something smart > there. > I haven't looked in that code yet, but I'm guess it should be pretty > trivial. > > Then comes the kernel. :( I started looking that the ILOAD code in > mga_state.c. Basically, it looks like everything assume the source > buffers are in AGP space. I'm guessing that I could just look at the > > flags field in the drm_device_dma structure and only set the > MGA_SRCACC_AGP bit if _DRM_DMA_USE_AGP bit is set. Is > _DRM_DMA_USE_SG > *always* set for PCI DMA transfers? I don't want to exclude the > possability of sourcing vertex data from on-card memory in the > future. > > In the DRM, if there's no AGP available, then PCI memory has to be > used > for DMA. It looks like the setup for that happens in the DDX driver > in > MGADRIAgpInit (in mga_dri.c). In looking at that routine, it's not > immediatly clear what to do. Obviously, DRM_AGP wouldn't be passed > to > any of the drmAddMap calls. Looking at radeon_dri.c, it looks like > RADEONPciInit is the same as RADEONDRIAgpInit except it uses > DRM_SCATTER_GATHER instead of DRM_AGP and drmScatterGatherAlloc > instead > of drmAgpAcquire / drmAgpAlloc / drmAgpBind. Is that right? > > MGADRIPciInit wouldn't be a complete duplication of MGADRIAgpInit > because I don't intend to (initially) support PCIGART. Even when > PCIGART is supported, not all chips in the MGA family support it. Is > > the PCI G450 the only one? > > > There was a website with support for the PCI G450 (for alpha I think): http://www.instmath.rwth-aachen.de:8000/linux/G450-PCI/ However it seems to be down at the moment. Someone on the ML knew the guy who was doing the work. perhaps they an find out the state of it. As I recall the G450-PCI cards were just AGP chips with an agp to pci bridge. Perhaps you need to hack up an agpgart driver for the bridge? Also, for the pci g450, matrox only supported 3D on motherboards with intel chipsets for whatever reason. Alex __ Do you Yahoo!? Yahoo! Search - Find what youre looking for faster http://search.yahoo.com --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: PCI MGA support (was Re: [Dri-devel] mga cvs changes)
On Gwe, 2004-03-12 at 21:40, Ian Romanick wrote: > MGADRIPciInit wouldn't be a complete duplication of MGADRIAgpInit > because I don't intend to (initially) support PCIGART. Even when > PCIGART is supported, not all chips in the MGA family support it. Is > the PCI G450 the only one? Is there any easy way to find out from the card itself. I've got a PCI 220 here. The drivers I've touched which handle PCI bus (VIA, S3 (trying to ressurect it) and SIS6326 (buggy still)) all use their own memory allocators for the PCI side and don't go into PCIGART world. SiS supports only linear textures/buffers in main memory via PCI which is a problem to use because of the Linux memory allocator. --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: PCI MGA support (was Re: [Dri-devel] mga cvs changes)
Alex Deucher wrote: There was a website with support for the PCI G450 (for alpha I think): http://www.instmath.rwth-aachen.de:8000/linux/G450-PCI/ However it seems to be down at the moment. Someone on the ML knew the guy who was doing the work. perhaps they an find out the state of it. It's been down for at least a few weeks. I tried looking it up when I first found out this project might be coming my way. I just looked through the archives, and I found a couple more threads that I missed before on this topic: http://marc.theaimsgroup.com/?l=dri-devel&m=100631726630707&w=2 http://marc.theaimsgroup.com/?l=dri-devel&m=100707509032556&w=2 I don't think I'm so lucky as to have an iommu, but I don't know yet. Claus seems to have reached the same conclusion as I: the MGA DRM relies heavilly on AGP. Also, while his website is down, his anon cvs server is still up. :) http://marc.theaimsgroup.com/?l=dri-devel&m=102373024625910&w=2 As I recall the G450-PCI cards were just AGP chips with an agp to pci bridge. Perhaps you need to hack up an agpgart driver for the bridge? Also, for the pci g450, matrox only supported 3D on motherboards with intel chipsets for whatever reason. If possible, I'd like to leave that until later. Esp. since I don't have any docs for that. :( --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: PCI MGA support (was Re: [Dri-devel] mga cvs changes)
Alan Cox wrote: On Gwe, 2004-03-12 at 21:40, Ian Romanick wrote: MGADRIPciInit wouldn't be a complete duplication of MGADRIAgpInit because I don't intend to (initially) support PCIGART. Even when PCIGART is supported, not all chips in the MGA family support it. Is the PCI G450 the only one? Is there any easy way to find out from the card itself. I've got a PCI 220 here. Dunno. The drivers I've touched which handle PCI bus (VIA, S3 (trying to ressurect it) and SIS6326 (buggy still)) all use their own memory allocators for the PCI side and don't go into PCIGART world. SiS supports only linear textures/buffers in main memory via PCI which is a problem to use because of the Linux memory allocator. From reading some other messages in the archives, I think the G200 and G400, at the very least, work that way. That basically limits the driver to using 64k chunks, right? I don't think that should be a problem for vertex data, command buffers, and texture uploads. It just means you lose the ability to texture from PCI memory. I'm willing to make that sacrifice ATM. --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: PCI MGA support (was Re: [Dri-devel] mga cvs changes)
--- Ian Romanick <[EMAIL PROTECTED]> wrote: > Alex Deucher wrote: > > > There was a website with support for the PCI G450 (for alpha I > think): > > http://www.instmath.rwth-aachen.de:8000/linux/G450-PCI/ > > However it seems to be down at the moment. Someone on the ML knew > the > > guy who was doing the work. perhaps they an find out the state of > it. > > It's been down for at least a few weeks. I tried looking it up when > I > first found out this project might be coming my way. I just looked > through the archives, and I found a couple more threads that I missed > > before on this topic: > > http://marc.theaimsgroup.com/?l=dri-devel&m=100631726630707&w=2 > http://marc.theaimsgroup.com/?l=dri-devel&m=100707509032556&w=2 > > I don't think I'm so lucky as to have an iommu, but I don't know yet. > > Claus seems to have reached the same conclusion as I: the MGA DRM > relies > heavilly on AGP. Also, while his website is down, his anon cvs > server > is still up. :) > > http://marc.theaimsgroup.com/?l=dri-devel&m=102373024625910&w=2 > > > As I recall the G450-PCI cards were just AGP chips with an agp to > pci > > bridge. Perhaps you need to hack up an agpgart driver for the > bridge? > > Also, for the pci g450, matrox only supported 3D on motherboards > with > > intel chipsets for whatever reason. > > If possible, I'd like to leave that until later. Esp. since I don't > have any docs for that. :( > You do now! looks like PLX owns HiNT now and they have the databooks on their website. according to this thread: http://marc.theaimsgroup.com/?l=dri-devel&m=102373024625910&w=2 the pci g540 uses the Hint HB1-SE33 bridge. PLX bought HiNT and changes a few names: http://www.plxtech.com/products/hint/naming.htm but makes the specs available here: http://www.plxtech.com/products/hint/6152.asp Alex __ Do you Yahoo!? Yahoo! Search - Find what youre looking for faster http://search.yahoo.com --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: PCI MGA support (was Re: [Dri-devel] mga cvs changes)
Alex Deucher wrote: --- Ian Romanick <[EMAIL PROTECTED]> wrote: Alex Deucher wrote: As I recall the G450-PCI cards were just AGP chips with an agp to pci bridge. Perhaps you need to hack up an agpgart driver for the bridge? Also, for the pci g450, matrox only supported 3D on motherboards with intel chipsets for whatever reason. If possible, I'd like to leave that until later. Esp. since I don't have any docs for that. :( You do now! looks like PLX owns HiNT now and they have the databooks on their website. according to this thread: http://marc.theaimsgroup.com/?l=dri-devel&m=102373024625910&w=2 the pci g540 uses the Hint HB1-SE33 bridge. PLX bought HiNT and changes a few names: http://www.plxtech.com/products/hint/naming.htm but makes the specs available here: http://www.plxtech.com/products/hint/6152.asp HmmI wonder what bridge chip the G450-for-POWER board actually uses, then. It's a semi-custom board, and all the POWER systems I know of have 66MHz, 64-bit PCI slots (or PCI-X). I wonder if it uses one of the other chips. I guess I'll have to wait to find out until Airborne actually delivers the box to my office. :) --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: PCI MGA support (was Re: [Dri-devel] mga cvs changes)
> Then comes the kernel. :( I started looking that the ILOAD code in > mga_state.c. Basically, it looks like everything assume the source > buffers are in AGP space. I'm guessing that I could just look at the > flags field in the drm_device_dma structure and only set the > MGA_SRCACC_AGP bit if _DRM_DMA_USE_AGP bit is set. Is _DRM_DMA_USE_SG > *always* set for PCI DMA transfers? I don't want to exclude the > possability of sourcing vertex data from on-card memory in the future. > > In the DRM, if there's no AGP available, then PCI memory has to be used > for DMA. It looks like the setup for that happens in the DDX driver in > MGADRIAgpInit (in mga_dri.c). In looking at that routine, it's not > immediatly clear what to do. Obviously, DRM_AGP wouldn't be passed to > any of the drmAddMap calls. Looking at radeon_dri.c, it looks like > RADEONPciInit is the same as RADEONDRIAgpInit except it uses > DRM_SCATTER_GATHER instead of DRM_AGP and drmScatterGatherAlloc instead > of drmAgpAcquire / drmAgpAlloc / drmAgpBind. Is that right? If the card has non PCI GART (like ATIs have), you can probably still use the machine's IOMMU to perform like an AGP GART, that is create a mapping of scattered memory pages that is shown as contiguous for your card. The current PCI interface to the iommu doesn't allow you to explicitely ask an sg list to be force-merged into a single segment though that could be added via some platform hooks. That would probably work if that is the only DMA allocation you do on this TCE table. Those machines have a TCE table per PCI brigde and one bridge per slot, no ? Ben. --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: PCI MGA support (was Re: [Dri-devel] mga cvs changes)
On Fri, Mar 12, 2004 at 01:40:30PM -0800, Ian Romanick wrote: > > I want to initially support this by just "disabling" AGP texturing. I > looked in the DRI driver, and it looks like this can be done with some > trivial changes in mga_xmesa.c. Basically, the code just needs to > handle the case where serverInfo->agpTextureSize is 0. The DDX driver > needs to be modified to detect PCI cards and do something smart there. I think the chip detection for the DRI driver should be in the DRM. I have this in my local Mesa 5 tree. I just added a new getparam ioctl that returns the PCI id. But since G450 PCI doesn't have a unique PCI id we'd need something slightly different. > I don't want to exclude the > possability of sourcing vertex data from on-card memory in the future. The cards can't do this. > MGADRIPciInit wouldn't be a complete duplication of MGADRIAgpInit > because I don't intend to (initially) support PCIGART. Even when > PCIGART is supported, not all chips in the MGA family support it. Is > the PCI G450 the only one? I think so. G200 was the last chip to have a real PCI variant but none of the chips can do scatter gather. I've never heard of PCI G400 or G550. Of course even AGP chips can use PCI transfers but that might only make sense for something like video capture. Currently the DMA buffers are 64 kB but if we would reduce them to PAGE_SIZE we could perhaps support all PCI cards. The only problem is the primary buffer since it's 1 MB currently. And switching to PAGE_SIZE buffers might require even more space in the primary buffer. I haven't actually measured how full the buffers are typically... -- Ville Syrjälä [EMAIL PROTECTED] http://www.sci.fi/~syrjala/ --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id70&alloc_id638&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: PCI MGA support (was Re: [Dri-devel] mga cvs changes)
On Fri, Mar 12, 2004 at 03:39:50PM -0800, Alex Deucher wrote: > > > As I recall the G450-PCI cards were just AGP chips with an agp to > > pci > > > bridge. Perhaps you need to hack up an agpgart driver for the > > bridge? > > > Also, for the pci g450, matrox only supported 3D on motherboards > > with > > > intel chipsets for whatever reason. > > > > If possible, I'd like to leave that until later. Esp. since I don't > > have any docs for that. :( > > > > You do now! looks like PLX owns HiNT now and they have the databooks > on their website. according to this thread: > http://marc.theaimsgroup.com/?l=dri-devel&m=102373024625910&w=2 > the pci g540 uses the Hint HB1-SE33 bridge. PLX bought HiNT and > changes a few names: > http://www.plxtech.com/products/hint/naming.htm > but makes the specs available here: > http://www.plxtech.com/products/hint/6152.asp I just had a look at the docs and didn't see any mention of an address translation table :( Is the bridge only used because they needed to connect a 66Mhz AGP device to a 33MHz PCI bus? -- Ville Syrjälä [EMAIL PROTECTED] http://www.sci.fi/~syrjala/ --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id70&alloc_id638&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: PCI MGA support (was Re: [Dri-devel] mga cvs changes)
Benjamin Herrenschmidt wrote: Then comes the kernel. :( I started looking that the ILOAD code in mga_state.c. Basically, it looks like everything assume the source buffers are in AGP space. I'm guessing that I could just look at the flags field in the drm_device_dma structure and only set the MGA_SRCACC_AGP bit if _DRM_DMA_USE_AGP bit is set. Is _DRM_DMA_USE_SG *always* set for PCI DMA transfers? I don't want to exclude the possability of sourcing vertex data from on-card memory in the future. In the DRM, if there's no AGP available, then PCI memory has to be used for DMA. It looks like the setup for that happens in the DDX driver in MGADRIAgpInit (in mga_dri.c). In looking at that routine, it's not immediatly clear what to do. Obviously, DRM_AGP wouldn't be passed to any of the drmAddMap calls. Looking at radeon_dri.c, it looks like RADEONPciInit is the same as RADEONDRIAgpInit except it uses DRM_SCATTER_GATHER instead of DRM_AGP and drmScatterGatherAlloc instead of drmAgpAcquire / drmAgpAlloc / drmAgpBind. Is that right? If the card has non PCI GART (like ATIs have), you can probably still use the machine's IOMMU to perform like an AGP GART, that is create a mapping of scattered memory pages that is shown as contiguous for your card. The current PCI interface to the iommu doesn't allow you to explicitely ask an sg list to be force-merged into a single segment though that could be added via some platform hooks. That would probably work if that is the only DMA allocation you do on this TCE table. Those machines have a TCE table per PCI brigde and one bridge per slot, no ? You lost me at "PCI interface". :) I don't currently know very much about POWER at all, so you're going to have to bear with me a bit. As far as I can tell, the PCI bridge on the card doesn't do anything except convert regular PCI voltage to AGP voltage. I'm not at all familiar with the TCE table, but it sounds like a more general version of an AGP GART table. Is that a fair assessment? From skimming the kernel source briefly, it looks like this is only supported on PPC64. Is that correct? If so, it sounds like something PPC64-specific could be done to keep the performance up, but I think I want to do something more general as well. I see no reason to exclude support for PCI cards on x86, for example. I now understand why some IHVs have complained that Linux can't allocate large (i.e., more than a page) of physically contiguous memory. Of course, I've always understood why it doesn't. (And never will! Muhahaha!) :) --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: PCI MGA support (was Re: [Dri-devel] mga cvs changes)
> > The current PCI interface to the iommu doesn't allow you to explicitely > > ask an sg list to be force-merged into a single segment though that > > could be added via some platform hooks. That would probably work if > > that is the only DMA allocation you do on this TCE table. Those machines > > have a TCE table per PCI brigde and one bridge per slot, no ? > > You lost me at "PCI interface". :) I mean the Linux PCI DMA mappings interfaces. > I don't currently know very much > about POWER at all, so you're going to have to bear with me a bit. As > far as I can tell, the PCI bridge on the card doesn't do anything except > convert regular PCI voltage to AGP voltage. I'm not at all familiar > with the TCE table, but it sounds like a more general version of an AGP > GART table. Is that a fair assessment? Somewhat ... > From skimming the kernel source briefly, it looks like this is only > supported on PPC64. Is that correct? If so, it sounds like something > PPC64-specific could be done to keep the performance up, but I think I > want to do something more general as well. I see no reason to exclude > support for PCI cards on x86, for example. I now understand why some > IHVs have complained that Linux can't allocate large (i.e., more than a > page) of physically contiguous memory. Of course, I've always > understood why it doesn't. (And never will! Muhahaha!) :) No, amost all 64 bits architectures have an iommu. Ben. --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
