[Dri-devel] Re: OB6100 agpgart problem / patch
ok Bjorn,
I think I got it. Thanks again for the info.
I went to developer.intel.com and read about the i830 chipset and, like
you said the 830M and 830MG have an integrated graphics chipset, where
the 830MP does not (I have a radeon :) ).
So...
In the detection / initialization tables, the 830 is defaulted to the
intel_generic_setup, but this is never called, as
you can see from:
static int __init agp_find_supported_device(void)
...
case PCI_DEVICE_ID_INTEL_830_M_0:
...
printk(KERN_INFO PFX Detected an Intel
830M Chipset.\n);
agp_bridge.type = INTEL_I810;
return intel_i830_setup(i810_dev);
This seemed odd to me, since these cases seem to handle exceptions to
the standard routines.
So, I changed:
i810_dev = pci_find_device(PCI_VENDOR_ID_INTEL,
PCI_DEVICE_ID_INTEL_830_M_1,
NULL);
if(PCI_FUNC(i810_dev-devfn) != 0) {
i810_dev = pci_find_device(PCI_VENDOR_ID_INTEL,
PCI_DEVICE_ID_INTEL_830_M_1,
i810_dev);
}
to:
i810_dev = pci_find_device(PCI_VENDOR_ID_INTEL,
PCI_DEVICE_ID_INTEL_830_M_1,
NULL);
if (!i810_dev) {// no integrated graphics chip
i810_dev = pci_find_device(PCI_VENDOR_ID_INTEL,
PCI_DEVICE_ID_INTEL_830_M_2,
NULL);
if (i810_dev) // we at least found PCI bridge
break;// probably an i830MP
// try generic_intel_setup
}
if (i810_dev) {
if(PCI_FUNC(i810_dev-devfn) != 0) {
i810_dev =
pci_find_device(PCI_VENDOR_ID_INTEL,
PCI_DEVICE_ID_INTEL_830_M_1,
i810_dev);
}
}
i.e. If we don't find the integrated chip, at least be sure we have the
PCI bridge. If so, we're probably the 830MP, and should break from the
exception routines and just called the intel_generic_setup, which was
set in the initialization tables here:
...
{ PCI_DEVICE_ID_INTEL_830_M_0,
PCI_VENDOR_ID_INTEL,
INTEL_I830_M,
Intel,
i830M,
intel_generic_setup },
...
Anyway, thanks tons for your help! I'm including the patch in this
message (against redhat srpm kernel-2.4.15-0.3)
and CC:ing dri-devel and redhat kernel maintainer.
PS. Also included are gltestperf results.
Bjorn Helgaas wrote:
Your init changes look reasonable. I wonder if this ever worked on any
830 chipset. It just looks broken to me.
From a quick look at the specs (from developer.intel.com), the 810 appears
to have only two PCI devices:
7120 Graphics Memory Controller Hub
7121 Chipset Graphics Controller
while the 830 has three:
3575 something like the GMCH
3576 AGP bridge
3577 integrated graphics device
Actually, I guess the 830 comes in three flavors, the 830MP, 830M, and
830MG, and the 3577 is not present on the 830MP, which must be what you
have. Maybe the existing code DOES work, but only on 830M and 830MG?
I don't know if the 810 device #1 (7121) combines the functionality of the
3576 and 3577 in the 830 or what. In any case, you changed it to look for
the 3576, which seems to make sense, but then the code goes on to
reference MMADDR, which is a CSR in the 3577. The offset of MMADDR (0x14)
is reserved in the 3577, so I'm not surprised that you get zeroes back.
I'll have to read the specs more to see what MMADDR is and what the 830MP
ought to do. On the face of it, it looks like a graphics device CSR,
which would correspond to something in Radeon for you. I suppose the
integrated graphics devices have the AGP bridge and the actual graphics
device all mixed up together or something.
Bjorn
diff -Pru kernel-2.4.15.orig/linux/drivers/char/agp/agp.h
kernel-2.4.15/linux/drivers/char/agp/agp.h
--- kernel-2.4.15.orig/linux/drivers/char/agp/agp.h Fri Nov 9 15:01:21 2001
+++ kernel-2.4.15/linux/drivers/char/agp/agp.h Wed Dec 12 01:12:48 2001
@@ -176,6 +176,9 @@
#ifndef PCI_DEVICE_ID_INTEL_830_M_1
#define PCI_DEVICE_ID_INTEL_830_M_1 0x3577
#endif
+#ifndef PCI_DEVICE_ID_INTEL_830_M_2
+#define PCI_DEVICE_ID_INTEL_830_M_2 0x3576
+#endif
#ifndef PCI_DEVICE_ID_INTEL_820_0
#define PCI_DEVICE_ID_INTEL_820_0 0x2500
#endif
diff -Pru kernel-2.4.15.orig/linux/drivers/char/agp/agpgart_be.c
kernel-2.4.15/linux/drivers/char/agp/agpgart_be.c
--- kernel-2.4.15.orig/linux/drivers/char/agp/agpgart_be.c
Re: [Dri-devel] Re: OB6100 agpgart problem / patch
Troy A. Griffitts wrote: ok Bjorn, I think I got it. Thanks again for the info. I went to developer.intel.com and read about the i830 chipset and, like you said the 830M and 830MG have an integrated graphics chipset, where the 830MP does not (I have a radeon :) ). So... Hello Your mail waked up a neuron of mine ;-) I have made a cleaner patch for the i830MP agp support (the generic stuff is not really so generic). It has not been integrated in the kernel yet, but Marcelo swore that he would put it in the next 2.4.18-pre series. In the mean time, you might want to give it a try Get it at http://ltswww.epfl.ch/~aspert/patches/patch-agp_i830mp-2.4.16 It has been diffed against 2.4.16 but it should work without too much trouble on other kernels. Have fun ;-) Nicolas. -- Nicolas Aspert Signal Processing Laboratory (LTS) Swiss Federal Institute of Technology (EPFL) ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] fbdri, what's up ?
On Wed, Dec 12, 2001 at 10:13:41AM +0100, stephane conversy wrote: I wonder what's going on with fbdri (http://fbdri.sf.net). Is it stuck ? if so is it because of a lack of interest, a lack of developers, or because it's too cumbersome to do ? You'll need to ask over on their lists, this isn't the fbdri development list. Alan. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: OB6100 agpgart problem / patch
Get it at http://ltswww.epfl.ch/~aspert/patches/patch-agp_i830mp-2.4.16 Nicolas, Hey! Thanks! Where were you last week!? Your patch looks like you know what you're doing, whereas I just read the developer docs and hacked until it worked. You caught me just before sending to Marcelo. I'll yield to your previously sent patch. -Troy. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: OB6100 agpgart problem / patch
Troy A. Griffitts wrote: Nicolas, Hey! Thanks! Where were you last week!? Your patch looks like you know what you're doing, whereas I just read the developer docs and hacked until it worked. I was here ;-) but I saw no message containing sthg about i830 posted on dri-devel ... Anyway, I just did the same as you did, namely read the developer docs, and used copy/paste with slight changes :-) In fact a few guys on linux-kernel also showed me the secondary device stuff that caused an oops on 830MP-based machines You caught me just before sending to Marcelo. I'll yield to your previously sent patch. Keep me informed if you have any troubles... a+ -- Nicolas Aspert Signal Processing Laboratory (LTS) Swiss Federal Institute of Technology (EPFL) ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] gl extensions on/off
I think the point is (but I could be wrong) whether this is user-configurable without recoding/recompiling anything, and it seems the answer is no. That's bad. Definitely this is not high-priority issue, but it would be nice to have ability to enable/disable extensions without recompiling apps/drivers/etc. Well written apps should be able to determine which extensions are available (shouldn't them?) so it could be interesting to play with apps using different subsets of extensions. Anyway, thanks to everybody for comments. Sergey ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] comments for agpgart.h needed
Alexander Stohr wrote: possibly i am thinking a bit more practical: - the number of pages should never go negative, so why do we need the sign? - there is no reason why the number of pages should get limited to i.e. 2 GB instead of 4 GB on 32 bit machines. I think Phil *meant* 'unsigned int' instead of 'int' :-) - you are right in trying to distinguish number_of_bytes and number_of_elements by meance of different type defines for them. - i am not aware of a better type define - you might want to suggest a new one. Suggestion: typedef unsigned intelcount_t; or #define elcount_t unsigned int But to proove you the opposite: void *calloc(size_t nmemb, size_t size); nmemb = number_of_elements size = number_of_bytes (per element of course) so the usage is already a bit puzzled for other central areas. don't blame the agpgart programmers for introducing this... Yep, that's true... So using 'size_t' for element count seems to be a rather common thing (though 'calloc' is the only example I found so far ;-). The alternative of using another #define might make the code more readable, but we may also stick to the existing version and just add a few comments, s.t. people using it are not puzzled by the signification of the value. BTW, is 'size_t' an 'unsigned int' on every 32-bit platform ? and on the 64-bit ones ? Anyone knows about that ? a+ -- Nicolas Aspert Signal Processing Laboratory (LTS) Swiss Federal Institute of Technology (EPFL) ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] gl extensions on/off
Leif Delgass wrote: On Tue, 11 Dec 2001, Brian Paul wrote: Sergey V. Udaltsov wrote: Hi all Is it possible to turn on/off some particular GL extenstions in Mach64 driver? Is mesa.conf in any help here? I would like to play with texture-related extensions (probable, turning GL_ARB_multitextures off would solve my problems in celestia?) You can call the _mesa_enable/disable_extension() functions in the context-init code in the driver, like other DRI drivers do, to enable or disable various extensions. I'm not sure the mesa.conf stuff works anymore. I think the point is (but I could be wrong) whether this is user-configurable without recoding/recompiling anything, and it seems the answer is no. The driver can enable/disable extensions for all apps using the driver, or an app using GL through the driver can choose to enable or disable extensions supported by the driver. So it's up to the application (in this case celstia) to let the user configure which are used, right? Sure, an app can always elect whether or not it uses particular extensions. Maybe I'm missing your point. -Brian _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] gl extensions on/off
On 12 Dec 2001, Sergey V. Udaltsov wrote: I think the point is (but I could be wrong) whether this is user-configurable without recoding/recompiling anything, and it seems the answer is no. That's bad. Definitely this is not high-priority issue, but it would be nice to have ability to enable/disable extensions without recompiling apps/drivers/etc. Well written apps should be able to determine which extensions are available (shouldn't them?) so it could be interesting to play with apps using different subsets of extensions. I should point out that with the mach64 driver, there are some things still left to be implemented in the Mesa code, as it's still in development. I've also had problems with multitexturing and texture blending modes in other apps with this driver. So although the extension is currently exported by the driver, it probably still needs some work to get it working right: AGP texture uploads are not yet supported, for example. Many apps have a way to disable certain GL extensions, so that can be used as a workaround when available. At this stage though, it's probably best to try and find problems and fix the driver where possible. If an extension is exported, but doesn't work to spec, it's a bug. The ability to have the driver hide supported gl extensions could be useful too, but the app could always just refuse to work without them. :) --Leif --- Leif Delgass http://www.retinalburn.net ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 driver
Any info (or references to documents in XFree tree) would be highly appreciated... Finally, I managed to get and build (and even run) mach64 branch. Thanks to everyone who helped me. Now I use not Jose's binaries but the ones built on my own system. Nothing has changed (what a surprize!:) on my desktop: - 3D works faster than usual - No fog in the tunnel demoapp. - Textures have major problems (for example, on celestia) - 2D works rather slow (comparing to ATI drivers by V. Dergachev) :((( But I noticed the tree is not updating for weeks (the last file is dated 28.10). It seems, the development stopped again... :) :( Cheers, Sergey ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] gl extensions on/off
Sure, an app can always elect whether or not it uses particular extensions. Maybe I'm missing your point. An app? Probably. But some particular (very nice, BTW) apps still very dumb in terms of configuration so I'd like to have ability to turn extensions on/off myself, without modifying the app code (as a user). Anyway, this RFE has priority 0.0001 (where 1.0 is Normal). Cheers, Sergey ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] gl extensions on/off
Why force any application to implement some more or less wide set of external shell varibles to query while the same is much easier to maintain if its part of a gatekeeper library? Exactly! That's what I meant! Sergey ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] comments for agpgart.h needed
On Wed, Dec 12, 2001 at 01:36:10PM +0100, Alexander Stohr wrote: - the number of pages should never go negative, so why do we need the sign? - there is no reason why the number of pages should get limited to i.e. 2 GB instead of 4 GB on 32 bit machines. But we're talking page count, not byte count. So signed vs unsigned is something like having 8 vs 16 TERRABYTES addressable. Personally, I dont think that should be an issue :-) So allowing signed int for pagecounts, means you can allow -1 as a flag for uninitialized or something. Maybe not passing back to the user. But in internal routines that calculate pagecounts, etc. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] comments for agpgart.h needed
On Wed, Dec 12, 2001 at 01:36:10PM +0100, Alexander Stohr wrote: Suggestion: typedef unsigned intelcount_t; or #define elcount_t unsigned int Ack. Don't do that. -- Gareth ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] gl extensions on/off
On Wed, Dec 12, 2001 at 04:30:56PM +, Sergey V. Udaltsov wrote: Why force any application to implement some more or less wide set of external shell varibles to query while the same is much easier to maintain if its part of a gatekeeper library? Exactly! That's what I meant! Quake3 allows a user to selectively enable or disable its *use* of certain GL extensions. If this is the behaviour you want, then it's more an application thing than a driver thing. Look at some of the Mesa demos -- you may bind the 't' key to toggle multitexturing, for example. Environment variables in the driver are good for driver development, when the implementation of a certain extension may be buggy and thus disabled by default for instance. -- Gareth ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] comments for agpgart.h needed
But we're talking page count, not byte count. So signed vs unsigned is something like having 8 vs 16 TERRABYTES addressable. Personally, I dont think that should be an issue :-) well estimated. ;-) consider such a coding: size_t size_of_one_member, total_size_in_bytes; int number_of_members; total_size_in_bytes = size_of_one_member * number_of_members; this might cause some warnings due to the required type intermixing. storing similar objects in compatible types sounds reasonable to me. So allowing signed int for pagecounts, means you can allow -1 as a flag for uninitialized or something. a special value of zero is sufficient here. Maybe not passing back to the user. But in internal routines that calculate pagecounts, etc. with a -1 in that member all your calculations will need extra code for testing this or will give wrong results Regards Alex. PS: to Gareth - i dont do it, unless you give me CVS write permission... ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] comments for agpgart.h needed
On Wed, Dec 12, 2001 at 09:46:23PM +0100, Alexander Stohr wrote: [phil brown wrote] So allowing signed int for pagecounts, means you can allow -1 as a flag for uninitialized or something. a special value of zero is sufficient here. well, yeah, pagecount=0 is fine for an error flag :-) But when you're talking about page INDEX, aka page offset, thats another thing that should be plain signed int. off_t is really only supposed to be used for DISK OFFSETS. It even specifically says it is for disk offsets, if you do grep 'off_t;' /usr/include/sys/types.h under either BSD or Solaris. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
