Re: [Dri-devel] Re: 2.4.20 AGP for I845 wrong ?
David Dawes wrote: No, I think it should be intel_845_setup too, since the 845G docs on Intel's public web site show that the behaviour is like the 845 when the on-board graphics isn't enabled. I made that change in my locally maintained version of the agpgart driver a little while ago, but haven't had the opportunity to test it with an external AGP card in an 845G box yet. Damn, you're right. Now I got the docs from Intel (at the time were the patch to support 845g was submitted, they were just not available yet), and truly the specs are closer to the 845, so let's switch to 'intel_845_setup' to initialize the 845g. Not that it should change things too much, but it will avoid further confusions Best regards. Nicolas PS: I hope the IBM annoyances for mails sent to lkml stopped... -- Nicolas Aspert Signal Processing Institute (ITS) Swiss Federal Institute of Technology (EPFL) --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: 2.4.20 AGP for I845 wrong ?
Margit Schubert-While wrote:
From drivers/char/agp/agpgart_be.c
4554,4559
{ PCI_DEVICE_ID_INTEL_845_G_0,
PCI_VENDOR_ID_INTEL,
INTEL_I845_G,
Intel,
i845G,
intel_830mp_setup },
Surely this is wrong or ?
Should be intel_845_setup, I think.
IIRC, the 845G is a new version of the 830MP chipset (it had been
added by Abraham vd Merwe Graeme Fisher some months ago), but acts
basically just as the 830MP. Therefore the entry is correct Or maybe
if it gets confusing adding a comment would not hurt...
Also in drivers/char/drm/drm_agpsupport.h, the switch statement at 262
is missing the
cases for INTEL_I830_M, INTEL_I845_G.
That's true. It is also missing in 2.5.51.
I attach two patches, one for 2.4.21-pre1 and one for 2.5.51 that should
fix this.
Regards
Nicolas.
diff -ru linux-2.4.21-pre1.clean/drivers/char/drm/drm_agpsupport.h
linux-2.4.21-pre1/drivers/char/drm/drm_agpsupport.h
--- linux-2.4.21-pre1.clean/drivers/char/drm/drm_agpsupport.h Wed Dec 11 12:36:58
2002
+++ linux-2.4.21-pre1/drivers/char/drm/drm_agpsupport.h Wed Dec 11 12:42:34 2002
@@ -267,8 +267,10 @@
case INTEL_I810:head-chipset = Intel i810;break;
case INTEL_I815:head-chipset = Intel i815;break;
case INTEL_I820:head-chipset = Intel i820;break;
+ case INTEL_I830_M: head-chipset = Intel i830M; break;
case INTEL_I840:head-chipset = Intel i840;break;
case INTEL_I845:head-chipset = Intel i845;break;
+ case INTEL_I845_G: head-chipset = Intel i845G; break;
case INTEL_I850:head-chipset = Intel i850;break;
case VIA_GENERIC: head-chipset = VIA; break;
diff -ru linux-2.5.51.clean/drivers/char/drm/drm_agpsupport.h
linux-2.5.51/drivers/char/drm/drm_agpsupport.h
--- linux-2.5.51.clean/drivers/char/drm/drm_agpsupport.hTue Dec 10 03:45:39
2002
+++ linux-2.5.51/drivers/char/drm/drm_agpsupport.h Wed Dec 11 12:55:08 2002
@@ -271,10 +271,12 @@
#if LINUX_VERSION_CODE = 0x02040f /* KERNEL_VERSION(2,4,15) */
case INTEL_I820:head-chipset = Intel i820;break;
#endif
+ case INTEL_I830_M: head-chipset = Intel i830M; break;
case INTEL_I840:head-chipset = Intel i840;break;
#if LINUX_VERSION_CODE = 0x02040f /* KERNEL_VERSION(2,4,15) */
case INTEL_I845:head-chipset = Intel i845;break;
#endif
+ case INTEL_I845:head-chipset = Intel i845G; break;
case INTEL_I850:head-chipset = Intel i850;break;
case INTEL_460GX: head-chipset = Intel 460GX; break;
[Dri-devel] Re: 2.4.20 AGP for I845 wrong ?
Ooops... the patch I sent for 2.5.51 is wrong, since there I added a INTEL_I845 instead of a INTEL_I845_G (I know vim *does* weird things in my back 8-) Here is the correct one... Regards Nicolas. -- Nicolas Aspert Signal Processing Institute (ITS) Swiss Federal Institute of Technology (EPFL) diff -ru linux-2.5.51.clean/drivers/char/drm/drm_agpsupport.h linux-2.5.51/drivers/char/drm/drm_agpsupport.h --- linux-2.5.51.clean/drivers/char/drm/drm_agpsupport.hTue Dec 10 03:45:39 2002 +++ linux-2.5.51/drivers/char/drm/drm_agpsupport.h Wed Dec 11 12:55:08 2002 @@ -271,10 +271,12 @@ #if LINUX_VERSION_CODE = 0x02040f /* KERNEL_VERSION(2,4,15) */ case INTEL_I820:head-chipset = Intel i820;break; #endif + case INTEL_I830_M: head-chipset = Intel i830M; break; case INTEL_I840:head-chipset = Intel i840;break; #if LINUX_VERSION_CODE = 0x02040f /* KERNEL_VERSION(2,4,15) */ case INTEL_I845:head-chipset = Intel i845;break; #endif + case INTEL_I845_G: head-chipset = Intel i845G; break; case INTEL_I850:head-chipset = Intel i850;break; case INTEL_460GX: head-chipset = Intel 460GX; break;
[Dri-devel] Re: 2.4.20 AGP for I845 wrong ?
Dave Jones wrote: I'll check the chipset docs when I get time, and add a comment if necessary. No-one seems to be complaining that it isn't working, so I'm inclined to believe your diagnosis is correct. I found the thread of lkml containing the discussion about that ... here is the link to the original mail : http://marc.theaimsgroup.com/?l=linux-kernelm=102122146829865w=2 DRI folks, this seems like duplication given that this data is available in agpgart. How about changing this to read whatever agpgart has set in .chipset_name ? Sounds like a good idea to me ;-) Best regards Nicolas. -- Nicolas Aspert Signal Processing Institute (ITS) Swiss Federal Institute of Technology (EPFL) --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] 2.4.19-rc1 broke i815 agp support?
Slava Polyakov wrote: 2.4.19-pre10: version: 0.99 bridge id: 0x11308086 agp_mode: 0x1f000207 aper_base: 0xd800 aper_size: 64 pg_total: 82176 pg_system: 82176 pg_used: 0 entry.key : 0 entry.key : 1 Allocated 8 megs of GART memory MemoryBenchmark: 521 mb/s MemoryBenchmark: 606 mb/s MemoryBenchmark: 606 mb/s Average speed: 577 mb/s Testing data integrity (1st pass): passed on first pass. Testing data integrity (2nd pass): passed on second pass. That's OK. 2.4.19-rc1 open: no such device apprently i815 agp support got broken in 2.4.19-rc1. Yep, looks like something went wrong. I don't see any blatant error at the moment... Do you see something strange in your logs when doing a 'modprobe agpgart' ? And maybe also send the output of 'lspci -nv', just to be sure a+ -- Nicolas Aspert Signal Processing Institute (ITS) Swiss Federal Institute of Technology (EPFL) Office: ELE 237 Phone: +41 - 21 - 693 36 32 (LTS Office) Fax: +41 - 21 - 693 76 00 Web: http://ltswww.epfl.ch/~aspert --- This sf.net email is sponsored by: Jabber Inc. Don't miss the IM event of the season | Special offer for OSDN members! JabConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] 2.4.19-rc1 broke i815 agp support?
Slava Polyakov wrote: Nope... dmesg shows all the same with both kernels: [drm] AGP 0.99 on Intel i815 @ 0xd800 64MB [drm] Initialized radeon 1.3.0 20020521 on minor 0 Can you extract the agpgart bits from /var/log/messages (the drm is a different part) ? It should look like : Jun 10 17:09:09 ltslinux34 kernel: agpgart: Maximum main memory to use for agp memory: 203M Jun 10 17:09:09 ltslinux34 kernel: agpgart: agpgart: Detected an Intel i815, but could not find the secondary device. Assuming a non-integrated video card. Jun 10 17:09:09 ltslinux34 kernel: agpgart: Detected Intel i815 chipset Jun 10 17:09:09 ltslinux34 kernel: agpgart: AGP aperture is 64M @ 0xf800 a+ -- Nicolas Aspert Signal Processing Institute (ITS) Swiss Federal Institute of Technology (EPFL) --- This sf.net email is sponsored by: Jabber Inc. Don't miss the IM event of the season | Special offer for OSDN members! JabConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] 2.4.19-rc1 broke i815 agp support?
Hello There are some Intel815 AGP changes in 2.4.19-rc1, but I am not sure these are the problem. Can you try to run testgart to see if problems are really agp-related ? a+ -- Nicolas Aspert Signal Processing Institute (ITS) Swiss Federal Institute of Technology (EPFL) --- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] 2.4.19-rc1 broke i815 agp support?
Slava Polyakov wrote: I'm not sure where to find the testgart util (I am indeed running it on an i815B). Could you send me the tarball or give me a url to it? http://ltswww.epfl.ch/~aspert/patches/testgart.c or http://dri.sourceforge.net/res/testgart.c a+ -- Nicolas Aspert Signal Processing Institute (ITS) Swiss Federal Institute of Technology (EPFL) --- This sf.net email is sponsored by: Jabber Inc. Don't miss the IM event of the season | Special offer for OSDN members! JabConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Annouce: Major update of the FAQ
José Fonseca wrote: I've just updated the FAQ. Besides of including the new section about binary compatibility from Jens Owen I also added a new top section focusing on the implementation details, including new material covering topics such as texture management, Mesa's graphics pipeline and clipping. Now the DRI website also has the FAQ in other formats, available on http://dri.sourceforge.net/doc/faq/other-formats/. Hello I just noticed that the link in section 5.1.3 to the ATI AGP faq points to a 'page not found' :-( Maybe it have moved but maybe it has been simply removed. BTW, a copy of the 'testgart' program is on my web page, and the FAQ points to it (which is fine to me), but it may be a neat idea to have it also in the 'resources' of the DRI page, just to avoid the painful search to find a copy when I needed it... a+ -- Nicolas Aspert Signal Processing Institute (ITS) Swiss Federal Institute of Technology (EPFL) ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Intel 860 AGP bridge Support
Mike Westall wrote: We are presently acquiring a rather large cluster to build a distributed rendering system that will include some DRI related components. Some vendors responding to our bid have suggested replacing the specified 850 with the newer 860. Can anyone tell me if the existing DRI components are likely to work now (or soon) with the 860. thanks much, Mike Hello I assume you are looking for support under Linux. AGP for both 850 and 860 is working under Linux (at least in the recent kernels), so DRI should work on both chipsets, since AGP is the only chipset-dependent in DRI. Best regards Nicolas -- Nicolas Aspert Signal Processing Institute (ITS) Swiss Federal Institute of Technology (EPFL) ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] [goran@ucw.cz: drm_agpsupport.h]
Martin 'Goran' Moravec wrote: Hi, I've found something strange in reporting the chipset: I've got ATI R128 on VIA kt 266 chipset, Yet the driver writes: [drm] AGP 0.99 on VIA Apollo KT133 @ 0xe000 64MB [drm] Initialized r128 2.1.6 20010405 on minor 0 the chipset IS kt266 goran@glaugrung:~\ /sbin/lspci 00:00.0 Host bridge: VIA Technologies, Inc. VT8367 [KT266] 00:01.0 PCI bridge: VIA Technologies, Inc. VT8367 [KT266 AGP] I couldn't find why it doesnt report KT 266 how it should. any ideas? please cc: me, as I'm not on the list. Thanks. Goran Hello Which kernel version are you using ? Can you also send the output of 'lspci -nv' s.t. one can see whether your chipset is correctly detected ? 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] [goran@ucw.cz: drm_agpsupport.h]
Gareth Hughes wrote: The two chipsets have the same PCI ID, as far as I know. Thus, AGPGART will think it's a KT133. This shouldn't be a problem in general. I would be quite surprised if the two chipsets had the same PCI id (have a look at the pci.ids in the linux kernel)... they should only share the same vendor id, which makes the agpgart code work properly (I think Via is less silly than Intel that has the nasty habit of changing the adresses of AGP registers throughout their chipset releases) a+ -- Nicolas Aspert Signal Processing Laboratory (LTS) Swiss Federal Institute of Technology (EPFL) Office: ELE 237 Phone: +41 - 21 - 693 36 32 (LTS Office) Fax: +41 - 21 - 693 76 00 Web: http://ltswww.epfl.ch/~aspert ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] [goran@ucw.cz: drm_agpsupport.h]
Perhaps it was different revisions of the same chipset. I'm not sure
of the exact details, however I do remember someone complaining about
this fact.
Anyway, there is a correct entry for the chipset in agpgart_be.c :
{ PCI_DEVICE_ID_VIA_8367_0,
PCI_VENDOR_ID_VIA,
VIA_APOLLO_KT133,
Via,
Apollo Pro KT266,
via_generic_setup },
Martin, if you look in /var/log/message right after loading the agp
module, you should see sthg like Detected Via Apollo Pro KT266
The drm reports a KT133 stuff because the agp bridge is declared as
VIA_APOLLO_KT133.
(in drm_agpsupport.h : case VIA_APOLLO_KT133: head-chipset = VIA Apollo KT133;)
So anything should go smoothly (since all the via chipsets share the
same init. routine in the agp backend), even if the drm reports a KT133
bridge...
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] 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] 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] 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] program that uses /dev/agpgart?
Hello Have you checked that your AGP module is correctly loaded ? If so, I suggest that you compile and run (as root, and before running X) the C program located at : http://ltswww.epfl.ch/~aspert/patches/testgart.c Send the output of the program to the list... Best regards Nicolas. Philip Brown wrote: Hi folks, I'm back in my mission to slowly add DRI support for my platform. I'd like to start by just getting a basic /dev/agpgart working. It SEEMS like a simple tast. Trouble is, I cant find anything that will USE it. Xfree3.3.6 does not seem to use it at all. Xfree.4.1.0 has SOME code that references /dev/agpgart: os-support/lnx_agp.c Trouble is... nothing seems to USE the routines in lnx_agp.c, apart from the i810 drivers. Suggestions on how I can best test that my AGPGART driver works, without having to implement the entire drm set of interfaces? I have a few different cards; an Nvidia GeForce, and an mga400 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Matrox G450 - drawing out of the window....
Hello I have a Matrox G450 card on a RH7.1 Linux PC, XFree 4.0.3, and the latest driver from Matrox (v1.3.0) When running a OpenGL app., some strange things happen : if you move the OpenGL window, the application does not crash, but the GL context does not move, the rendering happens as if the window did not move (but nothing is drawn outside the new window position, only inside). Of course, no warning is shown, neither on the console, nor in the logs. However, if you set the env. variable LIBGL_ALWAYS_INDIRECT, everything goes back to normal. Has anybody got a clue about this ? Thanks in advance Nicolas -- Nicolas Aspert Signal Processing Laboratory (LTS) Swiss Federal Institute of Technology (EPFL) ___ Dri-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/dri-devel
