Re: [Dri-devel] Athlon/Kt133/Radeon QD system locking with 1GB ram
On Wed, 2002-01-23 at 13:56, Brian Paul wrote: FYI, the new issue if Linux Journal (february, page 78) has a technical support question regarding stability of a Soyo K7V Dragon/1.4GHz Athlon system. The system runs fine with 1GB of ram but is flaky with 1.5GB The responses to this problem basically ask if the one of the memory modules might be bad, or if one of the memory slots might be defective, or if the sytems may not be able to reliable power that much memory. Thanks for the reply, Brian. :-) Yes. Others have suggested that some boards do not like 3 dimm slots filled. Mine is *supposed* to be able to handle it from what I can tell. Is your system stable with 1.5GB of RAM when X is not running? Or, when X is running, but the DRI is disabled? I can bring the system up without X and run 'bonnie -s 2047M' concurrently with a kernel compile (make -j 16) along with 'top' and various interactive console apps. I ran through 2 complete compiles and everything seemed rock solid. I then brought up X and started a 3D app and locked up immediately. I will disable DRI and see if 2D X is then completely stable. I believe I have tried this in the past and found that without DRI enabled at all, 2D is stable but I'm not certain. For referencence the testing that I am doing today is with XFree 4.2-mdk from cooker and vanilla kernel 2.4.17. Thanks, Steve ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] S3 Savage IX/MX DRI support
Hi all, I guess this type of e-mail comes up every once in a while, but I see that the Utah-GLX project made a bit of headway with their support for the S3 Savage chip (a very popular chip with laptop manufacturers). However, I haven't seen too much on the Utah-GLX scene lately, and it would be nice to have GLX support for this chip with XFree86 v4. Has anyone been working on the DRI drivers? I might have considered trying to do it myself, but as yet I have no driver/GL programming experience, and little experience programming C in general. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Subject: Re: [Dri-devel] Athlon/Kt133/Radeon QD system locking with 1GB ram
On Wed, 2002-01-23 at 13:56, Brian Paul wrote: Is your system stable with 1.5GB of RAM when X is not running? Or, when X is running, but the DRI is disabled? Yes. I have now tested 2D X for about an hour now with the dri and glx modules *NOT* loaded at all. It seems quite stable running a KDE desktop + Konqueror + Evolution and some full screen mpegs. -Steve Bergman ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: S3 Savage IX/MX DRI support
On Wed, 2002-01-23 at 22:37, Eugene Brevdo wrote: Hi all, I guess this type of e-mail comes up every once in a while, but I see that the Utah-GLX project made a bit of headway with their support for the S3 Savage chip (a very popular chip with laptop manufacturers). However, I haven't seen too much on the Utah-GLX scene lately, and it would be nice to have GLX support for this chip with XFree86 v4. Has anyone been working on the DRI drivers? I might have considered trying to do it myself, but as yet I have no driver/GL programming experience, and little experience programming C in general. Actually I have started reading up on DRI which will hopefully end up in me trying to write a DRI driver for that chip (which is, as you say, a popular laptop chip - among others my own) from the Utah-GLX drivers. Perhaps a futile attempt, but what the heck... wish me luck :) / Mattias ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] ideal primitive rates?
Karl Czajkowski wrote: We have one particularly brute-force application that draws large batches of points (millions per frame) with low alpha value using an acculative blend mode and no z-buffer. I am curious what kind of performance is expected through the DRI in the long run. Using an Nvidia Quadro2Pro and their drivers, the application can sustain 30 Mpts/s draw rate into a 512x512 window. Using the DRI radeon driver it sustains only about 1.5 Mpts/s. Using a hand-coded software benchmark we get about 10 Mpts/s on both an 800 MHz PIII and a 1.7 GHz Xeon using MMX and SSE instructions. The opengl application draws the points in direct mode without vertex arrays or anything (we saw performance degradation when we tried vertex arrays a while back). The software benchmark is tuned to process small batches of about 1000 points to get good cache behavior and loop benefits. It uses SSE to do the perpsective vector transform on the 4x1 vertex, and MMX to do the saturating RGB blend into a 32-bpp pixel array. It also uses the SSE prefetch t1/nta instructions to good effect. The bottleneck in our benchmark appears to be the rasterization loop that draws an array of screen-coordinate points into the image. Turning off the MMX rasterization pass yields SSE vertex transform rates of 20 Mpts/s on the 800 MHz PIII and 30 Mpt/s on the 1.7 GHz Xeon. Would the DRI ever be expected to be as efficient as the Nvidia driver or our software benchmark for handling batches of primitives like this? Right now it looks like we would get a big win using our software pass and dumping the image into a GL window for display/GUI if we want to run the application on a radeon-equipped notebook. While we will have a TL driver for the radeon 7500 before too long, nvidia do have a good headstart and a lot of money to apply to the problem. At the moment, I'd ask if you've tried the mesa-4-0-branch version of the radeon driver - the code there should be a bit more efficient than on the trunk. If you wanted to post a simple GL program that excersizes the functionality, I can check if any bad code paths are being triggered accidentally. 1.5m vertices/second sounds low compared to the results I'm getting elsewhere, so there may be something going wrong. Keith ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] SOME ITEMS THAT YOU MAY BE INTERESTED IN OR BE ABLE TO ADVISE ME ON
These are the items that iam interested in selling.. Could you help me with some details on the goods, history, origin etc. are these worth anything and if so who would i contact with regards to selling them? and the best way to sell them ie auction etc APOLOGISE IF YOU HAVE ALREADY RECEIVED THIS E-MAIL JPEGS ARE AVAILABLE AT YOUR REQUEST MANY THANX kriss rolo tel: 0044 182760393 office (uk) 0044 1216864211 home (uk) 0044 7814294018 mobile (uk) return e-mail address [EMAIL PROTECTED] UK ONLY VEHICLE REGISTRATION NUMBER N64 CON NINTENDO 64 CONSOLE item 1 hand carved round table with metal chain link in the middle item 2 magnum laurent perrier vintage 1988 champagne item 3 miniture football on stand from euro96 signed by pele and bobby charlton item 4 is a bit more interesting. its a protana minifon attache, as u will see ive enclosed notes from a web site regarding this and you will see back in the 50's it cost $340.00 so i could imagine this to be worth a bit. it also has an original tape inside i do not know what is on this tape, but judging by who made it and the cost of the machine, the tape could have some important information on it. heres the note. The Minifon, developed in the early 1950s by Monske GMBH of Hanover(or by Protona GMBH- I'm not certain), was an ultra-miniaturized, battery operated magnetic recording device. It could not (initially at least) record the full range of sounds and was thus limited to voice recording, but it did offer easy portability in a very small package. The idea of offering a pocket dictating machine was novel, since dictation had previously been done in the office. However, it was thought that people like salesmen could take the machine on the road with them. Once on the market, the Minifon's promoters discovered that many people took advantage of the recorder's small size to make secret recordings to be used as evidence, as in court.BR BR The legitimate use of the Minifon, as a dictating machine, was somewhat problematical. Recordings made on regular dictating equipment were usually letters, and thus were normally sent almost immediately to a typist. The Minifon offered no obvious advantages over standard dictation equipment for office use, but its developers hoped to cultivate new uses for dictation equipment, such as stock taking in warehouses, or the use of the machine as a substitute for note-taking by reporters, insurance adjusters, salesmen, and others. In its original form, the Minifon was a wire recorder, using a type of wire medium developed by the Armour Research Foundation of Chicago and employed in many similar devices since the late 1940s. The machine at its introduction in 1952 had a recording time of one hour, which was remarkably long, and weighed only about 3 pounds at a time when a typical office dictating machine weighed upwards of 10 pounds. It accomplished this small size and light weight in part through the use of miniature tubes and clever mechanical design. The basic machine cost $289.50-- a price that sounds high today but was very much in line with competing office dictating machines. The parent company attempted to set up distribution, sales and service networks in the United States. It established a business office called the Minifon Export Corp in New York, and an existing company, Harvey Radio in New York City became the main distributor. Although smaller tape recorders appeared at about the same time, the main competition in the voice recording field was from an American company, Mohawk, which made a small, battery-operated cartridge tape recorder called the Migetape. Both products sold less than 10,000 units per year in the U.S.BR After a few years, the Minifon was modified to use transistors and magnetic tape, further lowering its weight and cost. By 1962 the basic machine weighed in at only 1.5 pounds. Competition by this time had helped bring the cost down to $249.50. The Minifon after about 1962 was distributed by the international conglomerate ITT through its subsidiary in the U.S., Federal Electric Corp. A little later, distribution was taken over by the ITT Distributor Products Division in Lodi, New Jersey. (I don't know whether these were the same company with different names) By the time ITT became associated with this product, it had taken on the name of Minifon Attache, and a new line of models and options appeared. These included a hi-fi model, the 978H, which sold for $330.50.Usinga two-track, 1/4 inch tape cartridge operating at 1 7/8 inches per second, the machine claimed a frequency response of up to 12,000 Hz, plus or minus 3db. The coming of magnetic tape did not completely displace wire. The Model 240 series of recorders introduced in the early 1960s were probably the last wire recorders in regular production. The 240L, at a price of $269.50 used a special long-playing wire cartridge that held 4 hours of wire. Otherwise it looked like both the tape model and the 240S,
Re: [Dri-devel] [PATCH] ioremap_nocache() support in DRM
On Wed, Jan 23, 2002 at 05:54:17PM +, Keith Whitwell wrote:
At the moment, DRM provides a wrapper for ioremap() but does not do so for
ioremap_nocache().. this is unfortunate, as a good number of framebuffer
drivers (probably X drivers as well) don't always want to remap in cached
space. This is a quick and dirty patch that adds an ioremap_nocache()
wrapper in the same way that ioremap() is treated..
This is against current CVS.. please apply.
This didn't seem to apply cleanly. Can you recheck the patch as sent? I
haven't investigated.
Odd. Applies just fine here. Will send it as an attachment this time..
Regards,
--
Paul Mundt [EMAIL PROTECTED]
MontaVista Software, Inc.
Index: drmP.h
===
RCS file:
/cvsroot/dri/xc/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/drmP.h,v
retrieving revision 1.45
diff -u -r1.45 drmP.h
--- drmP.h 2001/10/22 19:15:04 1.45
+++ drmP.h 2002/01/22 05:14:29
@@ -180,6 +180,9 @@
#define DRM_IOREMAP(map) \
(map)-handle = DRM(ioremap)( (map)-offset, (map)-size )
+#define DRM_IOREMAP_NOCACHE(map) \
+ (map)-handle = DRM(ioremap_nocache)((map)-offset, (map)-size)
+
#define DRM_IOREMAPFREE(map) \
do {\
if ( (map)-handle (map)-size ) \
@@ -622,6 +625,7 @@
extern void DRM(free_pages)(unsigned long address, int order,
int area);
extern void *DRM(ioremap)(unsigned long offset, unsigned long size);
+extern void *DRM(ioremap_nocache)(unsigned long offset, unsigned long size);
extern void DRM(ioremapfree)(void *pt, unsigned long size);
#if __REALLY_HAVE_AGP
Index: drm_memory.h
===
RCS file:
/cvsroot/dri/xc/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/drm_memory.h,v
retrieving revision 1.6
diff -u -r1.6 drm_memory.h
--- drm_memory.h2001/08/19 15:20:07 1.6
+++ drm_memory.h2002/01/22 05:14:36
@@ -314,6 +314,29 @@
return pt;
}
+void *DRM(ioremap_nocache)(unsigned long offset, unsigned long size)
+{
+ void *pt;
+
+ if (!size) {
+ DRM_MEM_ERROR(DRM_MEM_MAPPINGS,
+ Mapping 0 bytes at 0x%08lx\n, offset);
+ return NULL;
+ }
+
+ if (!(pt = ioremap_nocache(offset, size))) {
+ spin_lock(DRM(mem_lock));
+ ++DRM(mem_stats)[DRM_MEM_MAPPINGS].fail_count;
+ spin_unlock(DRM(mem_lock));
+ return NULL;
+ }
+ spin_lock(DRM(mem_lock));
+ ++DRM(mem_stats)[DRM_MEM_MAPPINGS].succeed_count;
+ DRM(mem_stats)[DRM_MEM_MAPPINGS].bytes_allocated += size;
+ spin_unlock(DRM(mem_lock));
+ return pt;
+}
+
void DRM(ioremapfree)(void *pt, unsigned long size)
{
int alloc_count;
msg02485/pgp0.pgp
Description: PGP signature
[Dri-devel] Question about MGA driver texturing patch
Hi, Back in June 2001, Karl Lessard posted the following patch to the mailing list: http://www.geocrawler.com/lists/3/SourceForge/680/0/5955984/ Are there any plans to incorporate this? I perused the latest CVS sources and wasn't able to find this in there. Thanks! ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Shared texture object problem
I have an OpenGL (Mesa) application that works fine except when I attempt to render the same texture objects in more than one window (GLX windows) at the same time, in which case the textures are incorrect and I get the following error message: Couldn't alloc placeholder sz 4 ofs 18 Memory heap 0x828db90: Offset:, Size:0004, U. ... I tracked the message down to the function mgaTexturesGone in the file: redhat-mesa-3.4.2/xc/lib/GL/mesa/src/drv/mga/mgatexmem.c I am trying to determine whether the problem is: 1) Improper use of OpenGL 2) Exceeding limits of framebuffer memory or some other allocation limit 3) Bug in DRI 4) other Does anyone have any ideas about this problem? Here is my configuration: RedHat Linux 7.2, Linux kernel 2.4.7-10 XFree86-4.1.0 XFree86-4.1.0-0.99.3-GLonly redhat-mesa-3.4.2 Dual CPU AMD Athlon (running in uniprocessor mode due to DRI problems) Matrox G450 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Was: Re: Athlon/Linux bug found --- Solution is under way!
Words from AMD came. It has something to-do with potential cache coherency interaction between Athlon speculative writes and the GART. Both Nvidia GART and kernel GART are concerned. Patches are under development if I understand it right. http://marc.theaimsgroup.com/?l=linux-kernelm=101181136132393w=2 Here are most answers from AMD: http://marc.theaimsgroup.com/?l=linux-kernelm=101177968601614w=2 Regards, Dieter -- Dieter Nützel Graduate Student, Computer Science University of Hamburg Department of Computer Science @home: [EMAIL PROTECTED] ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Shared texture object problem
Lynn Quam wrote: I have an OpenGL (Mesa) application that works fine except when I attempt to render the same texture objects in more than one window (GLX windows) at the same time, in which case the textures are incorrect and I get the following error message: Couldn't alloc placeholder sz 4 ofs 18 Memory heap 0x828db90: Offset:, Size:0004, U. ... I tracked the message down to the function mgaTexturesGone in the file: redhat-mesa-3.4.2/xc/lib/GL/mesa/src/drv/mga/mgatexmem.c I am trying to determine whether the problem is: 1) Improper use of OpenGL 2) Exceeding limits of framebuffer memory or some other allocation limit 3) Bug in DRI Probably a bug in the driver. This code hasn't been well excersized and is probably rotten. Feel free to investigate. Keith ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] i think i have a functioning FreeBSD SiS 630e/300 agp device. howdo i test it?
hi;
i have reason to suspect that i have successfully hooked up agp in my
FreeBSD kernel.
Why? because agp0 is now attached to a pci id that matches the one that
http://www.yourvote.com/pci/vendors.txt asserts is the agp port on the
SiS630
agp0@pci1:0:0: class=0x03 card=0x80351043 chip=0x63001039 rev=0x21
hdr=0x00
('chip' is the way the pci id called out in FreeBSD land)
this was not the case when i started out on this adventure, so i've hit my
first incremental milestone
ok dri guys, what's the most trivial piece of code that will tell me if
this is actually functional and acting agp-ish?
note that the answer to this question is an important bit of
fundamental dri-porting wisdom!
tnx!
johnu
--
John L. Utz III
[EMAIL PROTECTED]
Idiocy is the Impulse Function in the Convolution of Life
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] FreeBSD SiS 630e/300 drm port: who's favorite drm implementationshould i mindlessly copy?
hi again; is there a drm implementation in cvs that is looked upon with favor as being done 'more correctly than others'? is there a drm implementation in cvs that is looked upon with favor as being done 'more simply than others'? note that i have no expectation as to the shape of the venn diagram that describes the intersection or union of these 2 sets. tnx! johnu -- John L. Utz III [EMAIL PROTECTED] Idiocy is the Impulse Function in the Convolution of Life ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] how does drm handle chipset specific features in a generalized way?
one last question before i knock off for the nite suppose one has two cards. the first, the FooBarTech VisiBlaster, has special hardware for optimizing the generation of very realistic clouds. the second, the BazGrafix RadiantTurkeyBaster XL6000 AGP 4X Value Edition, has special hardware for optimizing the generation of very realistic hair. how would these get hooked up and taken advantage of? how many layers of abstraction get punctured by these nonstandard features? or am i asking the wrong question because they (every graphics chipset) are *all* non standard? can somebody point me to examples in the code? i'd like to be pointed at examples of graphics generation(the hair and clouds stuff) and examples of hardware operation ( ie turning on DVD decoding or enabling the tv-out signal path ). -- John L. Utz III [EMAIL PROTECTED] Idiocy is the Impulse Function in the Convolution of Life ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] how does drm handle chipset specific features in a generalized way?
On Thu, Jan 24, 2002 at 12:55:28AM -0600, John Utz wrote: one last question before i knock off for the nite suppose one has two cards. the first, the FooBarTech VisiBlaster, has special hardware for optimizing the generation of very realistic clouds. the second, the BazGrafix RadiantTurkeyBaster XL6000 AGP 4X Value Edition, has special hardware for optimizing the generation of very realistic hair. how would these get hooked up and taken advantage of? how many layers of abstraction get punctured by these nonstandard features? or am i asking the wrong question because they (every graphics chipset) are *all* non standard? can somebody point me to examples in the code? i'd like to be pointed at examples of graphics generation(the hair and clouds stuff) and examples of hardware operation ( ie turning on DVD decoding or enabling the tv-out signal path ). You'd probably implement an OpenGL extension. The NV_* extensions are nVidia specific extensions as examples. How closely this matches your hardware depends on the API you design and the features of the hardware. For it to get accepted as a standard part of OpenGL it would have to be reviewed by the OpenGL architecture review board (ARB). If there were multiple vendors who implemented the feature then the API might need to be changed to standize it. This is one of the current issues with pixle shaders, because the ATI and nVidia API are different, and they've got to get to a common standard accepted by the ARB members. (There's many more issues there, but that's one.) Things like DVD decoding or TV out are even more different. They wouldn't be part of OpenGL at all. They might be X extensions. They might or might not use the DRM as part of their implemention. - |Daryll ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
