Re: [Dri-devel] kernel 2.6.1 - supersavage
From: Marco Strack [EMAIL PROTECTED] ok, changed the code and recompiled the source. Now the drm module recognizes the card and inits it. [...] in X log : [...] this is drm stuff : [...] (**) SAVAGE(0): DRI is enabled (II) SAVAGE(0): virtualX:1400,virtualY:1050 (II) SAVAGE(0): bpp:32,tiledwidthBytes:5632,tiledBufferSize:5947392 (II) SAVAGE(0): bpp:32,widthBytes:5632,BufferSize:5914624 check: align(1400, [32,128]) = 1408 check: 5632 / 4 = 1408 this looks sane to me. (EE) SAVAGE(0): Memory manager initialization to (0,0) (1408,-1) failed this -1 looks broken to me. I think someone is passing a wrong height value for the possibly needed memory mamnager initialitation. some of the code maintainers should be able to locate and correct that problem with only a minor effort. but there might be lots more of problems in the current codebase which i cant understand them due to current lack of insights. -Alex. --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] valgrinding DRI..
in the past Valgrind was likely to choke on anything but pure gcc generated assembler and binary code. this means an sort of hand coded assembler, non-default calling convention and alikes could bring that checker to a halt. to my best knowledge you could not even guide that tool to ignore specific modules or routines, no blacklist method or alikes applicable. -Alex. -Original Message- From: Brian Paul [mailto:[EMAIL PROTECTED] Sent: Thursday, December 11, 2003 15:54 To: Dave Airlie Cc: [EMAIL PROTECTED] Subject: Re: [Dri-devel] valgrinding DRI.. Dave Airlie wrote: I'm trying to valgrind my application and in the process DRI :-), However I can't get over the Mesa MMX checks, is there any env variable I can set so Mesa doesn't do all the stuff that requires SIGFPE and I can force it to use a certain type of instruction set? Try setting the MESA_NO_MMX and/or MESA_NO_ASM env vars before running. I've been just setting ALWAYS_INDIRECT for now but that doesn't find any issues in my DRI driver (not that I think there are any but it never hurts to look)... Dave. -Brian --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] FW: S3 TwisterK...
the admin list got this, i think it is ment to the main list. forwarding it now, just to get it right... -Original Message- From: TA [mailto:[EMAIL PROTECTED] Sent: Monday, December 08, 2003 19:55 To: [EMAIL PROTECTED] Subject: S3 TwisterK... Hi DRi Team! I've got a notebook with S3 TwisterK, I'd like to use Linux, but only with hardware opengl support. I'd like to ask, that will next DRI driver package have ProSavage and Twister support? If not, when will have? Many Thanks! Bye! Best Wishes: Antoine Trifonov --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
admin note RE: [Dri-devel] mach64-0-0-6-branch dri bug report
just a few words for the future, nothing serious... -Original Message- From: Christopher Gleba [mailto:[EMAIL PROTECTED] Sent: Thursday, December 04, 2003 23:02 To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: [Dri-devel] mach64-0-0-6-branch dri bug report Size: 220 kB i am pretty sure that an e-mail of that size might be qualified to get handled as a bugzilla bug report. at least only the folks that want the full set of attachments have to download them if they do want them. -Alex. --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] Application performance: open source vs proprieta ry?
sorry for going off topic now, the following is not tightly related to dri development works but only to the embedding reallity in the real world of software development. From: Pawel Salek [mailto:[EMAIL PROTECTED] for recently released game Savage that was even announced on Slashdot. I tried it on my ATI8500LE (I know it is not a state-of-the-art graphics card any more) and I have got mixed feelings. DRI drivers could render only single frame every few seconds and had usual problems with s3TC but the program can be asked not to compress textures - I wish it could detect the missing extension automatically as ID-software games do. The DRI drivers dont have a problem with S3TC, they simply dont expose those patented color format. If there is a problem, then there is the problem that patents do have problem with free software and open source such as XFree86 licensed or GPL licensed software - if the S3TC ownership consortium (better say the grafics industry and Microsoft and some companys that dont do grafics at all) would like Free Software to have S3TC then they are free to do so - but they seem to have a problem doing so. If a computer game is unable to detect S3TC presence then it can be considered flawed - if it were open source, you could fix that and provide a patch. Since it is not OpenSource, you have to work around this in a less pleasant manner and hope that the software vendor will fix it for you somedays. -Alex. --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] AGP 8x support
not beeing totally deep into the drm-radeon driver...
excerpt of agp command register,
when chipset is in AGPv3 mode:
bit 3, value 8: reserved
bit 2..0, value 0: agp transfer mode not yet programmed
value 1: agp transfer mode 4x
value 2: agp transfer mode 8x
value 3-7: reserved
the sheme in the hardware is different than below proposed patch.
maybe it's a different encoding that is used in radeon_dri.c,
i hope someone else can do a more qualified comment on this patch.
-Alex.
-Original Message-
From: Dmitri Katchalov [mailto:[EMAIL PROTECTED]
Sent: Thursday, November 27, 2003 15:47
To: [EMAIL PROTECTED]
Subject: [Dri-devel] AGP 8x support
Greetings,
It appears that DRI does not quite support AGP 8x and AGP3.0
in general, please correct me if I'm wrong.
I've made this quick and dirty patch for Radeon driver only.
I understand that it is not perfect as it has to be copied
into every other driver. A better solution is needed IMHO.
As a side note I'm now getting a whooping 1% improvement with
AGP 8x according to ut2003 benchmark. I wonder is there is
something else I should look at. BTW I'm running Radeon 9200
with linux-2.6.0-test9 and the latest (as of today) DRI CVS.
Also AGPFastWrite locks up my machine hard, is this to be expected?
Regards,
Dmitri
diff -r -x CVS
DRI-CVS/xc/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_dri.c
DRI-CVS.new/xc/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_dri.c
723,726c723,758
switch (info-agpMode) {
case 4: mode |= RADEON_AGP_4X_MODE;
case 2: mode |= RADEON_AGP_2X_MODE;
case 1: default: mode |= RADEON_AGP_1X_MODE;
---
if (mode RADEON_AGP_MODE_3_0) {
switch (info-agpMode) {
case 8:
mode |= RADEON_AGP3_8X_MODE;
break;
case 4:
mode |= RADEON_AGP3_4X_MODE;
break;
default:
xf86DrvMsg(pScreen-myNum, X_WARNING,
[agp] mode x%d not supported in AGP 3.0,
forcing 4x mode\n,
info-agpMode);
mode |= RADEON_AGP3_4X_MODE;
break;
}
} else {
switch (info-agpMode) {
case 4:
mode |= RADEON_AGP2_4X_MODE;
break;
case 2:
mode |= RADEON_AGP2_2X_MODE;
break;
case 1:
mode |= RADEON_AGP2_1X_MODE;
break;
default:
xf86DrvMsg(pScreen-myNum, X_WARNING,
[agp] mode x%d not supported in AGP `2.0,
forcing 4x mode\n,
info-agpMode);
mode |= RADEON_AGP2_4X_MODE;
break;
}
diff -r -x CVS
DRI-CVS/xc/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_dri.h
DRI-CVS.new/xc/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_dri.h
55c55
#define RADEON_AGP_MAX_MODE 4
---
#define RADEON_AGP_MAX_MODE 8
diff -r -x CVS
DRI-CVS/xc/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_reg.h
DRI-CVS.new/xc/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_reg.h
73,75c73,78
# define RADEON_AGP_1X_MODE 0x01
# define RADEON_AGP_2X_MODE 0x02
# define RADEON_AGP_4X_MODE 0x04
---
# define RADEON_AGP2_1X_MODE 0x01
# define RADEON_AGP2_2X_MODE 0x02
# define RADEON_AGP2_4X_MODE 0x04
# define RADEON_AGP3_4X_MODE 0x01
# define RADEON_AGP3_8X_MODE 0x02
# define RADEON_AGP_MODE_3_0 0x08
---
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
---
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] Application performance: open source vs proprieta ry?
comments inline... From: Carl Switzky I'm new to this list, so please excuse me if this topic has been exhaustively discussed, or if it is not appropriate. I didn't see any way of searching the archives. There are archives, see dri.sf.net, page Mailing lists for the links. I'm interested in information on the comparative performance of OpenGL applications running with Mesa and other open source components available with XFree86 versus running with vendor proprietary DRI/DRM modules and libraries. Any references that discuss this topic or posted benchmarks would be appreciated. Mesa is the software renderer, thats merely XFree86 code and of course a project of its own (better say, a project from Brian Paul), but its tightly related since this code makes up the software rendering fallback if a driver does not come with his own open/closed soucre dri/drm hardware accellerated OpenGL implementation. There is a comparison from R.Scheidegger, it is linked at the dri web page at Documents page, Other Documents section comparing several Radeon 9000 capable drivers including the DRI drivers. Is there a general consensus about the relative performance between these two approaches? Software is slow - not really the interesting part anymore. Hardware is fast - state of the art on any current adapter. Is it possible to make this comparison for the high-end workstation cards from ATI, Nvidia, and 3DLabs? What about www.tomshardware.com - they drove a nice article from the german Linux Magazin (Doelle et.al.) from End 2002 comparing some current adpaters on the Linux platform. And there should be several others, Tom's team likes Linux. (Okay, xf86 dri can do more than just dumb Linux...) -Alex. PS: i just used the dri wiki at OpenDesktop and added the links that i meant, so i dont see a reason to duplicate all of them here. --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] Fwd: Your message to Dri-devel awaits moderator a pproval
you were the only one that hit those problem. i only have the very same problem report. the rest is driven by source forge internals. maybe its the yahoo origin paired with a quite random looking user name since you are using your initials. -Alex. -Original Message- From: Alex Deucher [mailto:[EMAIL PROTECTED] Sent: Thursday, November 20, 2003 16:10 To: [EMAIL PROTECTED] Subject: [Dri-devel] Fwd: Your message to Dri-devel awaits moderator approval Is anyone else having problems posting to the list? Alex __ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/ --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] Fwd: Your message to Dri-devel awaits moderator a pproval
oops, checked that and... yes, you are right. if the bounce repeats, then i will add you and Alex to the always approve listing. if the problem still persists then we must escalate this to sourceforge admins. -Alex. -Original Message- From: Mike Mestnik [mailto:[EMAIL PROTECTED] Sent: Thursday, November 20, 2003 17:16 To: Alexander Stohr; Alex Deucher Cc: [EMAIL PROTECTED] Subject: RE: [Dri-devel] Fwd: Your message to Dri-devel awaits moderator a pproval I get it too, maby letters and then numbers if it's not just anyone /w yahoo. --- Alexander Stohr [EMAIL PROTECTED] wrote: you were the only one that hit those problem. i only have the very same problem report. the rest is driven by source forge internals. maybe its the yahoo origin paired with a quite random looking user name since you are using your initials. -Alex. -Original Message- From: Alex Deucher [mailto:[EMAIL PROTECTED] Sent: Thursday, November 20, 2003 16:10 To: [EMAIL PROTECTED] Subject: [Dri-devel] Fwd: Your message to Dri-devel awaits moderator approval Is anyone else having problems posting to the list? Alex __ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/ --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel __ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/ --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] SPLIT_WC_REGIONS - anyone out there?
Hello, i stumbled across the above mentioned define and related code in the XFree86 sources (lnx_video.c). comparing X4.1.0 and X4.3.0 i found that the condtitnal coding of if (base % size) has vanished at some point in time and the handling is now hardcoded at this code location. to my best knowledge that coding is related to maybe the 3Dfx PCI memory regions layout with a single mixed framebuffer and register mapping. is any developer out there that is willing to describe the main points of that design in a few words. i am asking for that because i have had a case where the split code went into action despite any need and even the PCI range was a power of two. so in theory it should not happen. before popping up with any general solution i just wanted to make sure that i got the right idea of that code. to my understanding current mtrr implementations might be more flexible than it is assumed in the existing code. -Alex. --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] Re: [Dri-users] Finally DRI is On but slow fps
just if thas a pending duty... if the monitor refreshes at 75 Hz then the grafics adapter has no need for producing more then 75 frames per second. having images updated before the cathode ray has finished one image leads to showing two images in a single refresh cycle which looks bad. if you are rendering slower than 75 frames, you might show the same frame twice, but thats nearly not dramatical in image quality. there are means of ignoring the monitors refresh rate for e.g. benachmarking the board performance which is typically described as sync to vsync: off. as written, it looks bad if you let it render like that. -Alex. -Original Message- From: Keith Whitwell [mailto:[EMAIL PROTECTED] Sent: Saturday, October 18, 2003 18:23 To: Eddy Cc: [EMAIL PROTECTED]; Felix Kühling; dri-devel Subject: [Dri-devel] Re: [Dri-users] Finally DRI is On but slow fps Eddy wrote: Dear mailing list, I have been trying to get DRI working correctly but haven't succeeded obviously.. Many configurations failed for me. Here is a list of what I did: -Installing cvs's DRI + Finally having Xfree-4.0.3.99.x = wrong module version (radeon.o) -Recognizing radeon driver was built into the kernel statically -Switching off the Xfree-4.3.0 kernel-module = Xfree with DRI but not OpenGL (glxinfo says Off) -Reading that wrong libraries are used somehow -Installing Mesa -Meanwhile installing cvs's dri kernel modules in xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/ #make says that drm.o would be built but that hasn't been the fact here, only radeon.o is built for example. (For those who might have the problem that sound has gone automagically after that and don't know why.. a make in the directory mentioned above recompiles some kernel's modules as far as I have understood that) -Recognizing the library-confusion, installing cvs's DRI again (recovering the libs) + running ldconfig. Well.. and a bit more all over the day.. My problem is that at the point where DRI was recognized by XFree but not by glxinfo, glxgears worked with 1280 frames in 5 seconds or something like that.. When I finally got DRI recognized by glxinfo it workes with 75fp/s nearly constantly.. Someone in a chat told me that this isn't a desired effect. Therefore I am asking here, because I think I see a chance that my Radeon 7500 could work nicer. Or do all of you Radeon 7500 users have such low framerates? Felix -- Would you like to explain the vsync-by-default option to this gentleman? Keith --- This SF.net email sponsored by: Enterprise Linux Forum Conference Expo The Event For Linux Datacenter Solutions Strategies in The Enterprise Linux in the Boardroom; in the Front Office; in the Server Room http://www.enterpriselinuxforum.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel --- This SF.net email is sponsored by OSDN developer relations Here's your chance to show off your extensive product knowledge We want to know what you know. Tell us and you have a chance to win $100 http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] Adding hardware detection to DRI drivers
John, i gave your code a short review and found nothing worth a note. In other words, if there is a problem at all then i've overlooked that due to the speed i browsed it. One thing to ask you: there is always those secondary PCI ID on the current Radeon designs. Do you see some chance to get rid of irritating logfile messages that concern those 2nd ID. I currently do think of this operation for DRM(probe): return 0 = device not supported by this driver return 1 = device is supported by this driver return 2 = device is not useable and must be forecfully ignored in probing. What do you think? -Alex. -Original Message- From: Jon Smirl [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 15, 2003 19:12 To: dri-devel Subject: Re: [Dri-devel] Adding hardware detection to DRI drivers The attached patch adds a new DRM IOCTL: DRM_IOCTL_GET_SUGGESTED_UNIQUE. It works by hooking into the OS PCI device detection at module load time. Each DRM driver now contains the PCI IDs of all the cards that it supports. The OS then matches these to the hardware in the system. Current Xfree binaries will work unmodifed with this change. The new call is needed to support standalone Mesa. Standalone Mesa does not have the PCI probing code that is in Xfree. I'm also trying to make config files an option for standalone Mesa. To use it: open the DRM device IOCTL: DRM_IOCTL_GET_SUGGESTED_UNIQUE. IOCTL: DRM_IOCTL_SET_UNIQUE If you are familar with the hardware please check that I got the PCI ID lists right. The patch is against kernel 2.6.0-test7. I've been told that the same code should would with BSD but I don't run it. = Jon Smirl [EMAIL PROTECTED] __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] Website
i want to propose to integrate a link to the new WIKI pages to the Help FAQ section of the DRI homepage. further there was some sort of uncertainty to which XF86 version the current driver snapshots do apply. maybe some clarificatiion is needed in that area. as Liam is possibly unavailabel for a longer time (see below) i am now openly asking the website maintaince task to the audience. even postponing that task a bit due to current CVS movements onto the new server might be a viable way. -Alex. PS: the current site is good works - thanks Liam. -Original Message- From: Smitty [mailto:[EMAIL PROTECTED] Sent: Sunday, August 10, 2003 12:42 To: DRI developer's list Subject: [Dri-devel] Website Been real busy lately, so I'm going to unsubscribe from dri-users, and filter out bugzilla-daemon to delete without reading. Otherwise I just won't be able to read all the posts, this makes it a third less emails I have to read. Although now that I look at it, while dri-devel seems to be abused somewhat ie dri-user type questions are posted to dri-devel. The number of posts seem to indicate that more driver development (talk) is being done. Bottom line: If someone asks about the website they need to ask on dri devel in a normal posting to it. Liam it depends --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet _072303_01/01 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] what's the meaning of 'Graphics Aperture' in AGP?
The mainboard chipset provides two things in respect to the keyword AGP. - a high speed bus interface to the graphics controller - a memory paging uint exposed to the graphics controller and the CPU the 2nd is just a remapped view of the main memory, resembling some/any page of main memory in a new improved, linear order. aperture means nothing more than memory range. its a PCI config space based memory mapping to the physical bus address. your mainboard chipset should indicate that range on some of the first devices which typically either might be the host bridge/memory controller or the AGP bus bridge on the PCI bus config space. in theory you can call any PCI bus based mapped range an aperture. in practice the so called GART, AGP-GART or whatever this graphics aperture rante page translateion unit might be is the thing you do like. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] ??: [Dri-devel] what's the meaning of 'Graphics A perture' in AGP?
GART range a physical bus address including a size value, which will get fixed up by PCI config process in BIOS. It should not need any touching at a later time on sane systems. It can be reprogrammed in most cases but only with full system awareness. I dont know a regular reason why to do that on current designs. -Alex. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 17, 2003 12:47 To: Ryan Underwood Cc: [EMAIL PROTECTED] Subject: [Dri-devel] ??: [Dri-devel] what's the meaning of 'Graphics Aperture' in AGP? I find aperture base address in North bridge PCI offset 0x10h,for example,in my box,it is 0xb0 00 00 00 the base address is bus address or virtual address? It points to somewhere in system memory? -- ???: Ryan Underwood [mailto:[EMAIL PROTECTED] : 2003?9?17? 15:51 ???: [EMAIL PROTECTED] ??: Re: [Dri-devel] what's the meaning of 'Graphics Aperture' in AGP? Hi, On Wed, Sep 17, 2003 at 03:30:09PM +0800, Tao, Qian ( IES) wrote: I am a newbee in dri. Now i am reading agp source code in linux kernel. I am not clear about 'Graphics Aperture' I download AGP spec 2.0,but it don't say a word about it. what's the relationship between the aperture with graphics memory? thanks for any comment or replyBest Regards, IIRC, the aperture is the largest region of system memory that may be used for AGP DIME texture storage. (for Execute Mode) So if you set the aperture to 16MB, no more than 16MB of system memory can be used as non-local texture memory for the AGP card. -- Ryan Underwood, nemesis at icequake.net, icq=10317253 --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel N??X'u)Y\gbH zG( zx%C'^elqzm?X( ~zwXb?vz --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] ATI Radeon 9200 SE
Maybe the printed strings in your patch should mention the SE so that no one gets confused. Anything else looks smooth to me right now. -Alex. -Original Message- From: Michel Dnzer [mailto:[EMAIL PROTECTED] Sent: Saturday, September 13, 2003 22:08 To: #NGUYEN THANH NAM# Cc: [EMAIL PROTECTED] Subject: Re: [Dri-devel] ATI Radeon 9200 SE On Sat, 2003-09-13 at 17:13, #NGUYEN THANH NAM# wrote: I bought a Creative 3D Blaster 5 RX9200 SE (uses ATI Radeon 9200 SE chip). When I did a lspci the revision shown was 0x5964 (and there was another one too, I guess it is for secondary display). However, the radeon driver only supports 0x5960 to 0x5963 (I checked against the latest radeon-pci.h) #define PCI_CHIP_RV280_5960 0x5960 #define PCI_CHIP_RV280_5961 0x5961 #define PCI_CHIP_RV280_5962 0x5962 #define PCI_CHIP_RV280_5963 0x5963 So I was just wondering whether another line like this #define PCI_CHIP_RV280_5964 0x5964 would make it work for me. You also need to add it some other places, try this patch. -- Earthling Michel Dnzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] [PATCH] radeon mergedfb support for DRI CVS
I did some basic work on factoring out the common code and discussed it with Thomas Winischhofer (Sis maintainer and driving force behind mergedfb development). He is of the opinion that it is still too early to create a generic API for mergedfb. There is still no consensus on what the final look should be and whether or not we have a flexible enough model right now. Plus there are some new features in the pipeline that may require some reworking of the current common code (absolute offsets and panning domains). It's more of a pain to have to constantly update the common code. So at the moment I guess I'm inclined to agree. thoughts? Alex you would wonder how other developers could enjoy having a look on your updates at the time that they do happen. nothing worse than a driver which is based on that design but is outdated by weeks or even months relative to the top of the tree of your ongoing development. i would suggest having all your works going on in a CVS repository, prefereably some development branch like the texmem one. as the whole discussion takes place here at dri-devel and the major benefits seem to be (at least for me) on the dri project's behalf, i would vote for basing it at the dri's CVS server system. (lets hope that thing is working reliable for the next time.) to clarify, i would not mind having such a tree undergoing deep changes in a short time - anyone who wants can take an older snapshot or do its snapshot himselves. its just the point of sharing will improve any sort of growth here. of course there can be personal reasons like not beeing friend of CVS, having lots of broken code for long times or just the fact that a shared code database does need some sort of merger with other people's code any now and then. my personal expirience is that a compile any now and then plus some people that are testing such a codebase for functionality is a sufficient means for good results. -Alex. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] RE: 2 questions about radeon driver
CP mode means using an engine on the chip that gets the command data from main memory by itselves, some sort of busmaster DMA stream. MMIO means that the driver does program the chipset directly via its memory mapped registers. DRI means direct rendering and is the most common socket for current OpenGL implementation upon some kernel module supplied and shared resources. XAA is the 2D accelleration which can be done either in MMIO (helps quite a lot for bring up) or CP mode - it might make use of some kernel module supplied resources in CP mode. But there is no need or requirement that DRI is exposed in that mode, only the other way round if you are having DRI then its highly likely to have the XAA running in CP mode as well. therefore presence of HW accellerated OpenGL does indicate that the XAA is as well running in CP mode. If you need to know hos the XAA is operating then you should hook into the driver. its not common to let external applications know or even assume either state because they are outside of the 2D display driver. let me assume you are trying something that does go byond the concept - either you implement Xv functionality inside or close to the 2D driver or you are asking for heavy trouble. -Alex. -Original Message- From: Alex Deucher [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 19, 2003 21:50 To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: 2 questions about radeon driver I have two questions for you about the radeon driver. the first relates to the CP and accel. I'm attempting to convert the Xv code to use the CP. how do you check to find out if the driver is using CP or MMIO accel? I considered using info-directRenderingEnabled, but as far as I can see the radeon can use the CP for accel even if the DRI is disabled. It's probably obvious, I'm just missing it. secondly, is there a way we could switch to software rendering if the total width or height of or all rendering windows is larger than 2048? Since we seem to be hw limited by that, it'd be nice if the driver would just switch to software after 2048 rather than just showing a blank window or in some cases locking up the video card. It might be too much of a pain in the butt though... thanks, Alex __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel --- This SF.net email is sponsored by Dice.com. Did you know that Dice has over 25,000 tech jobs available today? From careers in IT to Engineering to Tech Sales, Dice has tech jobs from the best hiring companies. http://www.dice.com/index.epl?rel_code=104 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] Linux kernel PCI IDs vs Xfree
all info contained below is my personal opinion, should be retriveable from several pbulic sources and it is only accurate to my best knowledge. linux/pci_ids.h and xf86PciInfo.h are in disagreement for several Rage128 PCI ids. Xfree appears to be correct and the kernel file is wrong. This impacts the Rage framebuffer driver when loading. as long as no one notices or complains it cant be that big issue. ;-) I verified these with two PCI databases. Which ones? e.g. www.yourvote.com\pci is the database where the Linux kernel does get its listing. www.plasma-online.de is another site with a more or less bigger emphasize on getting even a photo of the packages. Rage Mobility 128 AGP 4x #define PCI_CHIP_RAGE128MF 0x4D46 #define PCI_DEVICE_ID_ATI_RADEON_LF 0x4d46 this chipset possibly went trough press announcements as Mobility M4, AGP 4x. i dont know the board names so the Rage Mobility 128 might match. 0x4d46 is ascii equivalent of MF, so the 2nd line sounds odd. Official Radeon-1 is counted (to my understanding) as equivalent to a Rage in 6th revison, so a 4 cant be a Radeon at all. Rage Mobility 128 AGP #define PCI_CHIP_RAGE128ML 0x4D4C missing Mobility M4, AGP 4x Rage 128 SE/4x PCI #define PCI_CHIP_RAGE128SE 0x5345 #define PCI_DEVICE_ID_ATI_RAGE128_RM0x5345 0x5345 == ASCII SE Rage 128 4x, PCI Rage 128 SF/4x AGP 2x #define PCI_CHIP_RAGE128SF 0x5346 #define PCI_DEVICE_ID_ATI_RAGE128_RN0x5346 0x5346 == ASCII SF Rage 128 4x, AGP 2x Rage 128 SG/4x AGP 4x #define PCI_CHIP_RAGE128SG 0x5347 #define PCI_DEVICE_ID_ATI_RAGE128_RO0x5347 0x5347 == ASCII SG Rage 128 4x, AGP 4x the 4x in the chip/card name is more of the evolution stage of the asic than the realized PCI/AGP bus speed. no idea how that RM trough RO came into the given macros. Rage 128 SH/4x #define PCI_CHIP_RAGE128SH 0x5348 missing 0x5348 == ASCII SH dont know if there was ever build such a chip revison. Rage 128 SK/4x #define PCI_CHIP_RAGE128SK 0x534B #define PCI_DEVICE_ID_ATI_RAGE128_RG0x534b 0x534B == ASCII SK Rage 128 4x, PCI Rage 128 SL/4x AGP 2x #define PCI_CHIP_RAGE128SL 0x534C #define PCI_DEVICE_ID_ATI_RAGE128_RH0x534c 0x534C == ASCII SL Rage 128 4x, AGP 2x Rage 128 SM/4x AGP 4x #define PCI_CHIP_RAGE128SM 0x534D #define PCI_DEVICE_ID_ATI_RAGE128_RI0x534d 0x534D == ASCII SM Rage 128 4x, AGP 4x the 4x in the chip/card name is more of the evolution stage of the asic than the realized PCI/AGP bus speed. no idea how that RG trough RI came into the given macros. Rage 128 4x #define PCI_CHIP_RAGE128SN 0x534E missing 0x534E == ASCII SN dont know if there was ever build such a chip revison. Rage 128 Pro Ultra TF #define PCI_CHIP_RAGE128TF 0x5446 #define PCI_DEVICE_ID_ATI_RAGE128_U10x5446 0x5446 == ASCII TF AGP 4x. might have flat panel interface - possibly laptop. Rage128 series, cant tell about board name. I cant tell if the U1 is the correct chip name but if considered an integrated design then might fit. Rage 128 Pro Ultra TL #define PCI_CHIP_RAGE128TL 0x544C #define PCI_DEVICE_ID_ATI_RAGE128_U20x544C 0x544C == ASCII TL AGP 4x. might have flat panel interface - possibly laptop. Rage128 series, cant tell about board name. I cant tell if the U2 is the correct chip name but if considered an integrated design then might fit. Rage 128 Pro Ultra TS #define PCI_CHIP_RAGE128TS 0x5453 missing 0x5453 == ASCII TS Rage128 series, cant tell about board name. I doubt the Ultra - it could even be a used for a Rage Fury MAXX board codenamed Aurora (see toms hardware) and later announced as a dual RAGE 128 PRO design. Rage 128 Pro Ultra TT #define PCI_CHIP_RAGE128TT 0x5454 missing 0x5454 == ASCII TT Rage128 series, cant tell about board name. I doubt the Ultra - it could even be a used for a Rage Fury MAXX board codenamed Aurora (see toms hardware) and later announced as a dual RAGE 128 PRO design. Rage 128 Pro Ultra TU #define PCI_CHIP_RAGE128TU 0x5455 missing 0x5455 == ASCII TU Rage128 series, cant tell about board name. I doubt the Ultra - it could even be a used for a Rage Fury MAXX board codenamed Aurora (see toms hardware) and later announced as a dual RAGE 128 PRO design. as initially written, no one complained for ages, so there is quite minor interest from users and maybe not even hardware availabel to developer hands to verify those chipsets and boards in the real world of x86 computer systems anymore. answered in best way of what i could find about those historic designs and what the world wide web plus the known device id encoding rules do tell me and anyone. anyways thats written on the fly and can be badly false but in the hope to contribute to discussion in a helpfull way. Jon, what are you planning to do with that now? Will
[Dri-devel] FW: What's going on DRI cvs server
can someone answer this request for DRI tarballs? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Monday, July 21, 2003 08:27 To: [EMAIL PROTECTED] Subject: AW: Request to mailing list Dri-announce rejected Importance: High Hello Admin, Thanks for your anser ... yes it's true that I have never read the archive ... SORRY ... now I have read, but could not find something about a actual tarball and how and where to get ... I have read on sf.net that admin could do a tarball for their cvs tree and put it on the web. Is there a complete tarball for DRI ... I hope .. and where to get Martin -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Gesendet: Samstag, 19. Juli 2003 23:35 An: [EMAIL PROTECTED] Betreff: Request to mailing list Dri-announce rejected Your request to the Dri-announce mailing list Posting of your message titled What's going on DRI cvs server has been rejected by the list moderator. The moderator gave the following reason for rejecting your request: Your message has been deemed inappropriate by the moderator. Daer Martin, the dri-announce mailing list is for the sole purpose of announcing special project related events, such as new releases. Your mail considers a question on one of the servers having malfunction. That does better match into dri-devl mailing list where developer problems and third party developer problems are discussed - please resent there. Concerning your question, it is a general sourceforge problem for some 3 weeks now that the pbulic CVS server access fails rather often. Its caused by a login limitation on the CVS server that should ensure that people that are in luck to get a connection will have sufficient performance to finish. That on the other side results in lots of people beeing randomly rejected at login. There is new hardware in preparation for SourceForge and will replace or extend the currently installed CVS public server so that anything will work again as before. I hope that does already answer your questions. BTW, the answer could already be found in the mailing list archives from other peoples postings, so i assume you have not searche the archives. -Alex. Moderator of dri-announce mailing list. Any questions or comments should be directed to the list administrator at: [EMAIL PROTECTED] --- This SF.net email is sponsored by: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here: http://www.vmware.com/wl/offer/345/0 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] radeon drm in 2.5.73
i am reading the list and i have not seen a fix for this. maybe the root cause is somewhere else, like using an uniprocessor config of an alternate CPU or a non current CPU desing (i686). if you hear about an answer, then please post to the list for letting people fix that. -Alex. -Original Message- From: Warren Turkal [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 24, 2003 04:54 To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: [Dri-devel] radeon drm in 2.5.73 I have a problem with the radeon drm in kernel 2.5.73. When modprobing the module, it comes back with radeon: Unknown symbol flush_tlb_all and won't load. This has been happening for at least 5 kernel versions I believe. Is there a known fix or patch that has not made it into the kernel proper? Thanks, Warren -- Treasurer, GOLUM, Inc. http://www.golum.org --- This SF.Net email is sponsored by: INetU Attention Web Developers Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel --- This SF.Net email is sponsored by: INetU Attention Web Developers Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] ATI R300/R350 documentation or drivers
try testing with the possible release-candidate drivers form www.schneider-digital.de for your purposes. it might be that the fglrxconfig program does fail the detection of R350 based boards (like the ATI Radeon 9800), simply ignore any such message and give `startx` a try. if drivers do reject your adapter (which i would doubt) then use the ChipID option for overriding this. (see `man XF86Config` for details on that switch. -Alex. -Original Message- From: Chris Cheney [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 18, 2003 08:18 To: [EMAIL PROTECTED] Subject: [Dri-devel] ATI R300/R350 documentation or drivers I am considering buying a R350 based video card. However, currently even the official binary only ATI drivers do not support it. I saw that earlier this year someone asked if ATI had released any documentation on the R300/R350 chipsets to the DRI developers for 3D support. At that time it appears they had not. Does anyone know if they have supplied the needed documentation yet? Thanks, Chris Cheney --- This SF.Net email is sponsored by: INetU Attention Web Developers Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel --- This SF.Net email is sponsored by: INetU Attention Web Developers Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] subscribers only policy established
for dri-announce, dri-devel, dri-users, dri-patches i have now enabled the mailman option member_posting_only. this is done for stopping the major portion of spam as we have seen it coming via the list in recent times. dri-announce already was set to the aproval plight, so there wont shift anything at all for that list. if you do need to send from elsewhere than your subscribed reader account then you have to subscribe from that account as well. you might want to disable delivery in that case, see respective options page. if that sheme does not work for you for some reasons, then please contact one of the list administrators for configuring an excemption from non-subscribers rule. same if a known-as-good person pops up to often on the administrators task list. i further tuned the number of allowed addresses in mail headers a little bit in order to less impact discussions with a bigger number of directly addressed people. that change should not have any impact on the spam issue in 99.9%. -Alex. --- This SF.Net email is sponsored by: INetU Attention Web Developers Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] subscribers only policy established
for dri-announce, dri-devel, dri-users, dri-patches i have now enabled the mailman option member_posting_only. this is done for stopping the major portion of spam as we have seen it coming via the list in recent times. dri-announce already was set to the aproval plight, so there wont shift anything at all for that list. if you do need to send from elsewhere than your subscribed reader account then you have to subscribe from that account as well. you might want to disable delivery in that case, see respective options page. i further tuned the number of allowed addresses in mail headers a little bit in order to less impact discussions with a bigger number of directly addressed people. that change should not have any impact on the spam issue in 99.9%. -Alex. --- This SF.Net email is sponsored by: INetU Attention Web Developers Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] subscribers only policy established
seen that bunch of notifications and added a respective phrase to the setup. lets see if that was it. -Alex. -Original Message- From: José Fonseca [mailto:[EMAIL PROTECTED] Sent: Thursday, June 19, 2003 02:28 To: Alexander Stohr Cc: [EMAIL PROTECTED] Subject: Re: [Dri-devel] subscribers only policy established Alex, On Wed, Jun 18, 2003 at 09:18:17PM +0200, Alexander Stohr wrote: for dri-announce, dri-devel, dri-users, dri-patches i have now enabled the mailman option member_posting_only. this is done for stopping the major portion of spam as we have seen it coming via the list in recent times. dri-announce already was set to the aproval plight, so there wont shift anything at all for that list. if you do need to send from elsewhere than your subscribed reader account then you have to subscribe from that account as well. you might want to disable delivery in that case, see respective options page. i further tuned the number of allowed addresses in mail headers a little bit in order to less impact discussions with a bigger number of directly addressed people. that change should not have any impact on the spam issue in 99.9%. I think it would be better to open dri-patches to all @users.sourceforge.net otherwise commiters (which are subscribed with other email address besides the SF one or not subscribed at all) will receive the replies below: José Fonseca - Forwarded message from [EMAIL PROTECTED] - Date: Wed, 18 Jun 2003 17:10:36 -0700 From: [EMAIL PROTECTED] Subject: Your message to Dri-patches awaits moderator approval To: [EMAIL PROTECTED] Your mail to 'Dri-patches' with the subject CVS Update: xc (branch: trunk) Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. - End forwarded message - --- This SF.Net email is sponsored by: INetU Attention Web Developers Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] spam collection of the past few days
I've been a bit slack with it recently, so the numbers of posts have just been sitting there. You get daily reminders of how many are in the queue waiting for your attention too. But to be managed properly you need to tend to them on a daily basis. Alan I have no problem taking over that job on regular workdays. A second person would be helpfull to cover that thing on weekends. -Alex. --- This SF.Net email is sponsored by: INetU Attention Web Developers Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] Re: SPAM : DRI Devel ratio
Is the subsribers only policy now established? (lets hope that, i do agree with that) And the non-subscriber settings tuned to a notification about adminitrator decisison policy? (that would not be a friendly act even to non-subscriber) /me really wonders why the sourceforge servers do not allow for SPAM filtering software since its really a big problem for the full service. -Alex. Some other things worth considering too, are that people who want to post, but not to receive emails, can disable mailman from sending them mail. Also, mailman has an allways allow postings from these addresses setting, so that people who frequently send things in, and hit the admin queue, who's contributions are helpful/useful can either be subscribed by an admin, or added to the allow posts from this guy field. I use both of these techniques on a few decent sized lists, and people who post and it is rejected, almost always subscribe. Those who I allow their post through, which is rare, I may add to the allways allow list if I think they'll likely post again such as in response to mails CC'd to multiple lists and they're not on them, but their input is worthwhile. It's very little almost no admin overhead for me at least. Just some thoughts I hope are useful. TTYL -- Mike A. Harris --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] web page on CVS
on the web page, titled CVS fro the DRI, linked via CVS Web Page on the documentation page there is a comment for the mesa-4-0-4-branch with states: A Stable branch to be included in XFree86 4.3 XF86 4.3.0 is already out a few months, so that line obviousely needs an update. -Alex. --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] DRI Mailing list maintanence / maintaner
below is a sample how other lists do handle list submissions from non subscribers. on a second place i know that the adminstrators eased their job by setting a maximum hold time after which the mail will be passed trough unless an admin has canceled its delivery. I would further like to know if it is possible to install that same spam filtering on SF.net which David mentioned for the XFree86 mail lists. -Alex. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Saturday, February 15, 2003 06:45 To: [EMAIL PROTECTED] Subject: Your message to Flightgear-users awaits moderator approval Your mail to 'Flightgear-users' with the subject base package path contains a bad trap Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] ATI reference drivers
WineX is clobbering a register that the OpenGL part of the driver has already sort of claimed? Then their software is sort of broken. ;-) I have never tried WineX myselves in recent times but i am confident that the next ATI Linux driver release will address that thing so that this conflict is solved. -Alex. -Original Message- From: Ove Kaaven [mailto:[EMAIL PROTECTED]] Sent: Thursday, February 13, 2003 20:25 To: Alexander Stohr Cc: [EMAIL PROTECTED] Subject: RE: [Dri-devel] ATI reference drivers tir, 2003-02-11 kl. 12:26 skrev Alexander Stohr: development for the Linux platform has not stopped, surely not, it is just that there were no releases in the last two months or so. i have to admit that there were some problems as for any driver out there, but none was so fundamental serious that we felt it needed an instant driver update. I'm wondering - TransGaming sent in some feedback to ATI about these driver's use of the fs register, which conflicts with the Win32 threading model, replicated by Wine and WineX (TransGaming WineX is designed to run Windows games on Linux). Do you happen to know the status of this issue? --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] Unable to install VGA driver
The updated package might be for X4.2.0 whilst you have still portions of X4.1.0 on your system. That mixed up system revokes to run. Install a consistent XF86 environment and then install the _matching_ drivers. -Alex. -Original Message- From: Nitin [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 12, 2003 07:42 To: [EMAIL PROTECTED] Subject: [Dri-devel] Unable to install VGA driver Hello Everyone! Iam trying to install the following VGA driver for Intel(R) 82845 G/GL Graphics Controler on Rehat 7.1 ,kernel 2.4.x. i830-20030120-i386-linux.tar. Iam getting the following output with the error messages specified in the output. Please help. regards Nitin XFree86 Version 4.1.0 (Red Hat Linux release: 4.1.0-3) / X Window Sys (protocol Version 11, revision 0, vendor release 6510) Release Date: 2 June 2001 If the server is older than 6-12 months, or if your card is newer than the above date, look for a newer version before reporting problems. (See http://www.XFree86.Org/FAQ http://www.XFree86.Org/FAQ ) Build Operating System: Linux 2.4.7-0.13.1smp i686 [ELF] Build Host: stripples.devel.redhat.com Module Loader present (==) Log file: /var/log/XFree86.0.log, Time: Tue Feb 11 01:10:07 20 (==) Using config file: /etc/X11/XF86Config-4 Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown (==) ServerLayout Anaconda Configured (**) |--Screen Screen0 (0) (**) | |--Monitor Monitor0 (**) | |--Device RIVA TNT2 (**) |--Input Device Mouse0 (**) |--Input Device Keyboard0 (**) XKB: rules: xfree86 (**) XKB: model: pc105 (**) XKB: layout: us (**) FontPath set to unix/:7100 (**) RgbPath set to /usr/X11R6/lib/X11/rgb (==) ModulePath set to /usr/X11R6/lib/modules (--) using VT number 7 (II) Loading /usr/X11R6/lib/modules/fonts/libbitmap.a (II) Module bitmap: vendor=The XFree86 Project compiled for 4.1.0, module version = 1.0.0 (II) Loading /usr/X11R6/lib/modules/libpcidata.a (II) Module pcidata: vendor=The XFree86 Project compiled for 4.2.0, module version = 0.1.0 (EE) module ABI minor version (5) is newer than the server's version (II) Unloading /usr/X11R6/lib/modules/libpcidata.a (EE) Failed to load module pcidata (module requirement mismatch, 0) Fatal server error: Unable to load required base modules, Exiting... When reporting a problem related to a server crash, please send the full server output, not just the last messages. This can be found in the log file /var/log/XFree86.0.log. Please report problems to [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] . --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] ATI reference drivers
I really would like to buy an ATI card (9100 or 9500), but with no driver support I'll have to stay with Nvidia cards. Hope you have some info for me. Best regards Michael Born 9500 is a r300 based design and is nicely supported. 9100 is a r200 based design and is nicely supported. (or at least it should be quite nicely supported - just assumed because i dont have such a board to my hands.) development for the Linux platform has not stopped, surely not, it is just that there were no releases in the last two months or so. i have to admit that there were some problems as for any driver out there, but none was so fundamental serious that we felt it needed an instant driver update. ironic on in other words, due to the size of the package we did community a favour by not urging anybody to hunt for what is the latest greatest drivers. ;-) ironic off anything published next should be worth the download and should (hopefully) service several of the major topics. -Alex. PS: i am watching the list on an occasional base and i am watching the XF86 release shedules. --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] ATI reference drivers
i dont know much about that designs either. To my knowledge IGP and IGP 330 trough 350 is most close to the RV200 design. Therefore the Radeon driver will fit it best. The FGL codes are tailored to R200 and R300 so the OpenSource drivers are the closer ones. But i dont have such a device to my hands, so i cant test anything at all with that. -Alex. -Original Message- From: Alan Cox [mailto:[EMAIL PROTECTED]] Sent: Tuesday, February 11, 2003 13:59 To: Alexander Stohr Cc: [EMAIL PROTECTED] Subject: RE: [Dri-devel] ATI reference drivers On Tue, 2003-02-11 at 11:26, Alexander Stohr wrote: 9500 is a r300 based design and is nicely supported. 9100 is a r200 based design and is nicely supported. (or at least it should be quite nicely supported - just assumed because i dont have such a board to my hands.) Do you know what the status is for the Radeon IGP. At the moment it seems even the 2D for that doesn't work ? Alan --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] Confusing..?
I would just add that if you're using a kernel that uses a better source directory naming scheme (e.g. 2.4.19 unpacks to linux-2.4.19 whereas 2.4.18 unpacks to just linux), you'll want to use the TREE=/usr/src/linux-2.4.XX/include option in your make command. Like so: make -f Makefile.linux TREE=/usr/src/linux-2.4.XX/include MODULE.o for any recent kernel it works best with this change: TREE=/lib/modules/`uname -r`/build/include because build is an automatically created symlink that points to the build location of your kernel. this must not neccassarily be in the root's /usr/src dir. -Alex. and then as root: cp MODULE.o /lib/modules/`uname -r`/kernel/drivers/char/drm/ depmod -a --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] R100 GL_ATI_texture_env_combine3
first let me separate the framebuffer data from GL data by four more spaces. MGA r g b a amaskbsz ar ag ab aa Xvisual dpth 5 6 5 0 16 16 16 16 0 16 8 8 8 8 32 16 16 16 0 24 alphaMask should be 0xff00. In the argb READ_RGBA in mgaspan.c, alpha is always returned as 255. One or the other of these is wrong. Hmmm, I don't remember if the g200/400 supports dest alpha. The span functions would seem to indicate no. I've changed the mga_dri.c to report 0 for alpha bits, and 24 as the buffer size. Then result should be: MGA r g b a amaskbsz ar ag ab aa Xvisual dpth 5 6 5 0 16 16 16 16 0 16 8 8 8 0 24 16 16 16 0 24 it seems that no one never ever tried that alpha bits or used the bsz value. GLINT r g b a amaskbsz ar ag ab aa Xvisual dpth 5 5 5 5 000f1000 16 16 16 16 0 15 (pScrn-depth) 8 8 8 0 32 16 16 16 0 24 (pScrn-depth) This might be right. Looks OK. Shouldn't the buffer size be 24 here? Ooops, yes. Fixed. Assumed result: GLINT r g b a amaskbsz ar ag ab aa Xvisual dpth 5 5 5 5 000f1000 16 16 16 16 0 15 (pScrn-depth) 8 8 8 0 24 16 16 16 0 24 (pScrn-depth) Hey and why does 5+5+5+5 = 20, but sum up to 24 in your sheme? i mean the alpha bits would be only 1 bit (my prefrered thing, matches Xvis) or the bsz is truely 24 for the first line. (dont like that) here my prefered fix: GLINT r g b a amaskbsz ar ag ab aa Xvisual dpth 5 5 5 1 8000 16 16 16 16 0 15 (pScrn-depth) 8 8 8 0 24 16 16 16 0 24 (pScrn-depth) sorry i dont have that hardware handy or any specs nearby. -Alex. --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] Bug in compilation?
/usr/bin/ld: cannot find -lXpm collect2: ld returned 1 exit status make[6]: *** [xf86cfg] Error 1 make[6]: Target `all' not remade because of errors. check for existance of files ./lib/libXpm/libXpm.so* and ./exports/lib/libXpm.so* I assume those were not built or were cleaned up unintentional. If you will not see a Makefile and have not other clue, then please start over with a make world from the xc-base directory. -Alex. --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] 64-bit kernel, 32-bit user. Possible? Painful?
Title: RE: [Dri-devel] 64-bit kernel, 32-bit user. Possible? Painful? My question is, what are the gottchas of having the DRM run in a 64-bit kernel and the rest of the driver run in either a 32-bit application or a 64-bit application? Will it even matter? If it will matter, is there anything we can start doing now to soften the blow? We might have a problem here, basically we use the kernel address of certain structures as a convient method of passing keys around. Well, when a 64-bit kernel is running and we have 32-bit usermode we aren't going to be able to shove 64-bit pointers into 32-bit ulongs. We probably need to fixup all the kernel code so that it doesn't use the addresses as keys, but something else. most PCI devices only have 32 bit address spaces. maybe main memory will still reside below 4 GB for a while. so pointer truncation and physical address truncation from 64 to 32 bits will work for a while without flaws. but the question is justified. what can we do for that? in general i have heared Linux kernel people caring for some pooled memeory for specific tasks, like 24 bit DMA circuits. or for the lower 1 MB of memory (you know the good old A20 gate). if there are memory pools availabel then the driver must care for it, if an application uses the 32 bit api entry points. in other words, we will have to shedule for two sorts of entrypoints if the userland binaries will come in two bintess flavours (which might be nice because 32 bit could run faster thatn 64 bit could do for some cases). but its Linux and all should have the source to their applications so that they have to tailor their binarys to their machines. really? no not really. there is quite a significant amount of comercial software (games and professional CAD things) that still wants to run there as it got provided by its vendor. even Wine, WineX and all those big bunch of Win32 applications is 32 bits. There cannot be a well working intermediate layer, because the addresses cannot be down-converted by some library and the handles only with painfull efforts. Upscaling would be somewhat easier to do for bring up phase, unless someone comes with a 64 ponter for passing down. anyways in the long run, a 64 bit application wants a true 64 bit API if it wants to rund full featured and with full speed. I think we will have to fiddle with the co-existances of 32 bits and 64 bits on the same machine. -Alex.
RE: [Dri-devel] Newer Radeon cards and ATIs driver
Title: RE: [Dri-devel] Newer Radeon cards and ATIs driver have you tried parsing the extension strings? have you tried getting the function entry points with the gel/glx-get-by-name functions? That far that i am aware of, the Linux driver exports nearly the same set of extensions as the windwos driver does. its just that there is not wgl* set, but glx does have much of an equivalent for those sort of extensions. -Alex.
RE: [Dri-devel] Newer Radeon cards and ATIs driver
Title: RE: [Dri-devel] Newer Radeon cards and ATIs driver On Wed, Jan 22, 2003 at 06:15:13PM -0800, magenta wrote: good, though there's a LOT of apparent bugs in lighting and stencils; I'm going to probably be annoying the hell out of Alexander Stohr for a while ;) Do you know where bug reports can be reported? I have some problems specific to ATI binary drivers. Feedback form on ATI website? yes, the feedback form is the #1 official place for the ATI Radeon users.
RE: [Dri-devel] Re: 2.4.20 AGP for I845 wrong ?
Title: RE: [Dri-devel] Re: 2.4.20 AGP for I845 wrong ? Accoding to the official Linux pci database at http://www.yourvote.com the strings in the table should be: INTEL_I845, Intel, i845 E/MP/MZ, and INTEL_I845_G, Intel, i845 G/GL/GV/GE/PE, I think that would bring a lot more clarity to non-expert users. -Alex. -Original Message- From: Nicolas ASPERT [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 11, 2002 13:26 To: Dave Jones Cc: Margit Schubert-While; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: [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-kernel=102122146829865=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.
glTune Proposal (was RE: [Dri-devel] Smoother graphics with 16bpp on radeon)
Title: glTune Proposal (was RE: [Dri-devel] Smoother graphics with 16bpp on radeon) I was reading almost 80% of the discussion and want to give you a quite bold sheme of how that all can be handled in terms of a real world system: You'd write an extension to the drivers that advertises all queried enviromental strings. This should resemble a similar checking sheme as it is done for the exported gl extensions, the known driver specific config file options and for the imported XF86 module symbols. Any advertised environmental string is allowed by the XF86 system to be parsed by the drivers. On the client side there is a shell application which i will call `gltune` right now. This application just queries the libGL and the driver behind it for their respective environment parameters and further can query their current state and their default state. This application is able to write those values out to the shell: # current settings of libGL version 1.2 LIBGL_ALWAYS_INDIRECT=0 LIBGL_NUMBER_OF_LIGHTS=4 # current settings of r200 version 4.1.0 LIBGL_NO_TCL=0 LIBGL_MAX_LOD=6 (looks quite similar to what you might see with Samba config.) With this outputs you will get a full overview about the current state. You should be able to pass that data back to the shell. There should be a gltune program option that prefixes varies the outputs so that e.g. . sourcing with the bash is possible. For this there is no need for a write back option for the program but its possible to allow the program to perform the wrong way. Anyways, i dont think global options should get merged into such a per-client and per-terminal sheme. Of course there is a possibility of attaching a GUI tool to that ENV-NAMES extension, which then might make up Profile management, allowing to have a big bunch of help file in some central location and other ways of giving the ordinary skilled user good hints on every reported environment setting. Sample: Profile: Quake3 [Load] [Save] [Reset] [page1] [page2] [page3] Accelleration Level: [help] ( ) software rendering (o) hardware rendering w/o TCL ( ) hardware rendering with TCL [x] LIBGL_AA - enforces antialising [help] [6] LIBGL_MAX_LOD - level of detail [help] [browse unclassified only] [browse all] [Launch Application] [Launch Shell] [Quit] I am not a TCL/TK freak or whatever, but i think a set of config files should provide all extra information for a specific grafics adapter or if there is not yet a tailored config then it recognizes at least the basic switches and offers the remaining e.g. in an alphabethic listing. Help should be quite easy to maintain. You might get the idea behind now. I mean that will be ease of use - and it must really not break with the existing sheme. It's just a front end for serving to the low level. There is one drawback that i should not be silent about: you will not be able to deal with large amounts of environmental variables effectively because that checking and counter checking against lists will be time consuming. Generic vars like LIGHT_1 trough LIGHT_32767 arent target of those simple sheme. You see you can get anything from shell variables. Even the GUI frontend and the profiles. Flexibility is the nature of the shell vars in contrast to binary interfaces where you always have to fear about compatibility if only a single change happens. -Alex.
RE: [Dri-devel] Smoother graphics with 16bpp on radeon
Title: RE: [Dri-devel] Smoother graphics with 16bpp on radeon What about remote indirect rendering? Someone else has already mentioned that the driver would have no way of getting environment variables in that case. Remote indirect rendering is a problem no matter how you slice it. With a precise ENV-NAME method you cann tell the client what of the environment it should sent to the server. Maybe there is some way of sending the application name as well. This would mean auto-selecting profiles. Just specify a list of application names for each profile and you are done. But profile handling would result in a server specific new task. Looking at the drivers for the FireGL 4, it uses two cryptic 32-bit ints in XF86Config to communicate this to the driver. It's configuration tool has profiles for 4 different apps (including Maya Softimage). Admitedly, this isn't the right solution either, but it is another data point. Its a static way of specifying driver behaviour. Whilst programming for DirectX i was in duty for fixing dynmic resource allocation which were mutual exclusive to each other. For this i would not recommend to have anything configureable on a per application base. Just imagine concurrent start up and shut down of applications - when would you allow which feature? -Alex.
RE: [Dri-devel] Smoother graphics with 16bpp on radeon
Title: RE: [Dri-devel] Smoother graphics with 16bpp on radeon The layer idea is not bad, but its more the taste of a hack. Remember that dri is OpenSource, so you dont need those hacks. As soon as you start with that you will notice that a layer will increase distance between your application and the drivers on nearly any call. You dont really want that. Further you cant ensure that you covered all the paths because GL is an extensible system that might open highly relevant paths. And you might have to keep track of the numerous render state variables in order to keep the things in order and to know when to intercept and when not to intercept. I think its easier to turn on several features in the driver than somewhere else. Maybe there are features you can by no means control with the help of an intermediate level. (Remebering the FireGL big focus and Stereo support.) -Alex.
[Dri-devel] New ATI FireGL drivers announced (2.5.1)
Title: New ATI FireGL drivers announced (2.5.1)
Okay, driver version 2.5.1 has gone life.
Now the FireGL, the Built by ATI _and_
(newly) the Powered by ATI boards will run.
I hope that helps some of the reading people
and further offloads(!) these valueable dri-lists
from any unwanted traffic. Do not reply here!
For the sake of feedback use the ATI web-support form
in the first row, http://apps.ati.com/linuxDfeedback/.
Anyways those drivers are labled unsupported.
-Alex.
-Original Message-
From: Alexander Stohr [mailto:[EMAIL PROTECTED]]
Sent: Thursday, November 21, 2002 16:34
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: [Dri-users] New ATI FireGL drivers announced
Hello,
i know that DRI is targeting open source development,
but i know myselves that for a developer there can
always be a need for a 2nd source driver reference.
There are several other reasons why an alternate
Linux driver might be of interest for the audience.
So please excuse me for posting this information to your lists.
So this passed the news wires today:
ATI drives graphics performance for Linux users with new unified driver
http://mirror.ati.com/companyinfo/press/2002/4574.html
The drivers can now be downloaded for free at www.ati.com
(see e.g. Linux FireGL 8800).
The drivers should run on Linux/x86 with glibc 2.2,
some common kernel modules do come precompiled and
a build environment for gcc2.96 and gcc3.2 is included,
thus making that drivers compatible with
e.g. RedHat(R) Linux(R)/x86 8.0 or 7.3 versions.
Supported cards should be (list might not be complete):
- ATI Radeon 8500 {/DV/LE}, 9000 {/PRO}, 9500 {/PRO}, 9700 {/PRO} - Built by ATI
- ATI FireGL 8700, 8800, E1, X1, Z1/X1-128MB (just announced for retail), Mobility
I installed that drivers and tested them a tiny little bit.
Simple applications like glxgears do perform very well and
they are working quite nice for ut2003_demo (S3TC!), Maya and Houdini.
My impression is that things like Quake, Chromium or Blender should work.
I just had a few minutes of a one-man tournament session this noon.
I tried XVideo support and it showed that the CPU usage of TOP
was higher than that of the video player application. Features
that you will on FireGL boards are Overlays and PBuffer rendering
support.
Please excuse me again, i furthert want to give a few of the end
users an alternative to the dri drivers, which are often only
really useable if you do have downloaded som 60 MB of CVS sources
and built whole XF86 with a not totally trivial process.
Let me express that i do _not_ object to any of the DRI-Devel works.
DRI did great job and it resolves for situations where ATI
cant provide solutions as of today and possibly long term.
Just saying embedded Radeon chipsets, ATI chipsets on BSD,
old ATI chipsets prior to the R200 and further any sort of
experimental and custom extensions to the DRI open source
drivers.
Let's hope, no one does mind this mailing.
-Alex.
PS: not speaking for my employer, just documenting things that
are already publicly availabel.
RE: [Dri-devel] CVS issue - unresolved symbols from GLcore?
Title: RE: [Dri-devel] CVS issue - unresolved symbols from GLcore? I did notice that rendering has slowed down on the r200 driver by a magnitude of about 5 times. This of course isn't a very accurate measure purely based of glxgears frame rates, but it does make me raise an eyebrow. I will have to poke around to see what else I can see. Please ensure that you do not run with pure software rendering now. Check the renderer strings. -Alex.
[Dri-devel] drmOpen coding is incomplete
Title: drmOpen coding is incomplete drmOpen tries opening the drm device two times, but on second try it does trash that file handle in the case of success. the below patch does add the missing return statment for this case. -Alex. PS: the patch should nicely apply to current XF86 and DRI CVS code because sources there are identical. xf86drm.c.cvs.patch Description: Binary data
RE: [Dri-devel] Re: New ATI FireGL drivers announced
Title: RE: [Dri-devel] Re: New ATI FireGL drivers announced Hi, Alexander! It's a great news that ATI is making Linux driver for R200 boards, for completeness its: R200/RV250/R300/some-Mobility At first I attempted to set up SuSE's xfglrx package to get 3D acceleration for my Gigabyte AP64D board (actually it is a R200 QL with 64 Mb DDR RAM). The package included on SuSE CD set is not that up to date any more. Prefer the drivers from the web page. After generating XF86Config and typing startx in command prompt X server failed to start. I found in system logs that 2D driver refused to work with third party boards. That's Intentional. On the list you can find several references to problems with the multiple OEM BIOS variants even with the DRI drivers. Since this must be considered as third party software and hardware, you should consider calling the respective vendor for support. (Having a broken BIOS checksum is the least problem in that area...) It's nearly impossible to buy build by ATI board in Moscow, so I was forced to apply my assembly skills to modify board vendor id in 2D driver (fglrx_drv.o). After replacing ATI's id (0x1002) with Gigabyte (0x1458) I was able to start XFree but I saw my text consoles (vga=791) broken. This might be a BIOS problem. Current drivers are using the XFre86 Int10 module for doing mode switches. Thanks for another reason for not letting that drivers run on third party boards. Next thing I've tried is to start Tux Racer game. After 2 minutes of pretty smooth gameplay it hung and my box locked up completely. Stability of a specifc grafics board is mainly due to its clock rate, its RAM bus interface clock an signal quality plus misc power supply parameters (mainboard abilities to drive that board, PCB design to ensure the voltage does not drop critical in any operation thermal and electrical condtion). I know that ATI is ensuring this for the Built by ATI boards with much effort, but i have no idea how intense those third party vendors do that. The second unknown thing is your hosting PC system. You should verify it with a secondary operating system. I decided it's enough to uninstall this package and I started to look around for any alternative driver. I've downloaded official ATI driver version 2.4.0 and tried to install it. Official ATI drivers were 1.4.3 for R200, and are now unified with version 2.4.3 (the numbering similarity is a co-incidence). So i am wondering a bit who did supply such a driver to you. After install script built kernel drm modules installation stopped because depmod complained about unresolved symbols in module fglrx.o I am building these modules nicely on e.g. RedHat or with default kernel.org kernels. If something is missing from your kernel config (like module support, highmem support, whatever - see readme) then you might spot messages like this. Please check your kernel source configuration. Now I have installed driver from dri trunk, it works pretty well, but I have very slow gameplay with Loki's Rune. Thats the best and only drivers that should use for your adapter. Maybe today I will try to install official ATI driver again, this time version 2.4.3. I hope it finally going to work. What you were doing is unsupported and not recommended. This is meaning that it is on your own risk if you do it. Maybe there are legal reasons why you shouldn't be allowed to do that, but i dont know this myselves. -Alex.
RE: [Dri-devel] New ATI FireGL drivers announced
Title: RE: [Dri-devel] New ATI FireGL drivers announced What about support for other architectures, in particular PPC? The Apple as the #1 PPC platform (okay there might be several others) does have an AGP slot and to my knowledge there is a nice ATI history for the MacOS. Not bad the idea. It's a 32 bit platform, am i right? Or i am just confusing it with the DEC Alpha which is 64 bit. Anyone knows it there are Alpha's out that do have AGP slots? Let me express that i do _not_ object to any of the DRI-Devel works. DRI did great job and it resolves for situations where ATI cant provide solutions as of today and possibly long term. Just saying embedded Radeon chipsets, ATI chipsets on BSD, old ATI chipsets prior to the R200 and further any sort of experimental and custom extensions to the DRI open source drivers. Great to know the niche we have... I would call it a big and free developing space myselves. And i think it's a highly valueable thing, i know this since back to the times where was in school and had only a 6510 based Comodore home computer to my hands. -Alex.
RE: [Dri-devel] Re: New ATI FireGL drivers announced
Title: RE: [Dri-devel] Re: New ATI FireGL drivers announced I used stock SuSE 2.4.19-4GB kernel optimized for Athlon processors. Please try using a stock kernel.org kernel in the mean time. There might be need for us to check if there is a patch in the SuSE kernels that do impact system stability with our drivers. -Alex.
[Dri-devel] New ATI FireGL drivers announced
Title: New ATI FireGL drivers announced
Hello,
i know that DRI is targeting open source development,
but i know myselves that for a developer there can
always be a need for a 2nd source driver reference.
There are several other reasons why an alternate
Linux driver might be of interest for the audience.
So please excuse me for posting this information to your lists.
So this passed the news wires today:
ATI drives graphics performance for Linux users with new unified driver
http://mirror.ati.com/companyinfo/press/2002/4574.html
The drivers can now be downloaded for free at www.ati.com
(see e.g. Linux FireGL 8800).
The drivers should run on Linux/x86 with glibc 2.2,
some common kernel modules do come precompiled and
a build environment for gcc2.96 and gcc3.2 is included,
thus making that drivers compatible with
e.g. RedHat(R) Linux(R)/x86 8.0 or 7.3 versions.
Supported cards should be (list might not be complete):
- ATI Radeon 8500 {/DV/LE}, 9000 {/PRO}, 9500 {/PRO}, 9700 {/PRO} - Built by ATI
- ATI FireGL 8700, 8800, E1, X1, Z1/X1-128MB (just announced for retail), Mobility
I installed that drivers and tested them a tiny little bit.
Simple applications like glxgears do perform very well and
they are working quite nice for ut2003_demo (S3TC!), Maya and Houdini.
My impression is that things like Quake, Chromium or Blender should work.
I just had a few minutes of a one-man tournament session this noon.
I tried XVideo support and it showed that the CPU usage of TOP
was higher than that of the video player application. Features
that you will on FireGL boards are Overlays and PBuffer rendering
support.
Please excuse me again, i furthert want to give a few of the end
users an alternative to the dri drivers, which are often only
really useable if you do have downloaded som 60 MB of CVS sources
and built whole XF86 with a not totally trivial process.
Let me express that i do _not_ object to any of the DRI-Devel works.
DRI did great job and it resolves for situations where ATI
cant provide solutions as of today and possibly long term.
Just saying embedded Radeon chipsets, ATI chipsets on BSD,
old ATI chipsets prior to the R200 and further any sort of
experimental and custom extensions to the DRI open source
drivers.
Let's hope, no one does mind this mailing.
-Alex.
PS: not speaking for my employer, just documenting things that
are already publicly availabel.
RE: [Dri-devel] New ATI FireGL drivers announced
Title: RE: [Dri-devel] New ATI FireGL drivers announced By reading the readme, xinerma+dri is not yet supported. Is support planned for this? if so, when? To be honest, i just dont know because i am not that deeply involved in 2D development. Anyways, i wouldnt be allowed to talk about it. Company and business rules. -Alex. PS: looking for OpenGL 3.0 shedules myselves. *grin*
RE: [Dri-devel] mesa 4.1 branch / NO go on 2.5.48
Title: RE: [Dri-devel] mesa 4.1 branch / NO go on 2.5.48 GL_RENDERER: Mesa X11 GL_VENDOR: Brian Paul Yeah, that seems to be true for the mesa test programs I installed. Doing a regular glxinfo shows OpenGL renderer string: Mesa DRI R200 20021009 AGP 4x x86/MMX/SSE TCL OpenGL version string: 1.2 Mesa 5.0 You are running Software Mesa 5.0 :-O Naah, just the MesaDemos seem to use it for some reason, probably because I didn't know how to configure the build there correctly .. How do people build the Mesa demo package? It clearly doesn't build standalone, and apparently if you build it together with the MesaLib package it does the sw rendering thing). Linus Its a known issue for me, thats why i do prefer the GLUT demos. I made it to bring the Mesa demos to life on DRI by just editing the libGL and other references to the systems defaults rather than to the libs in the project. As far as i do remember, it all turned out to be rather static in linking. To my knowledge there is no simple way with this project build system for getting what we both do think of. -Alex.
RE: [Dri-devel] OpenGL 1.3, 1.4, and extension string issue
Title: RE: [Dri-devel] OpenGL 1.3, 1.4, and extension string issue From what I have been told, this is how it works on the Nvidia drivers. I have not verified this first hand. if ( extension string contains GL_EXT_texture3D ) 3D textures are hardware accelerated else if ( advertised OpenGL version = 1.2 ) 3D textures are a software fallback else 3D textures are not supported at all Nice sheme - this will even allow to check the software paths by just tuning the GL version (e.g. via environment variable). But what will you do if your software path is not yet covered by a specific OpenGL version but you still want to use it for testing your experimental application? -Alex.
RE: [Dri-devel] OpenGL 1.3, 1.4, and extension string issue
Title: RE: [Dri-devel] OpenGL 1.3, 1.4, and extension string issue Nice sheme - this will even allow to check the software paths by just tuning the GL version (e.g. via environment variable). But what will you do if your software path is not yet covered by a specific OpenGL version but you still want to use it for testing your experimental application? It doesn't help us much with that case, it's true. However we don't have that capability with the current scheme either. Keith setenv GL_SOFTWARE_EXTENSIONS_FORCE=GL_gamma GL_RGBA GL_whatever setenv GL_SOFTWARE_EXTENSIONS_ALLOW=GL_gamma GL_RGBA GL_whatever if ( is_in_list(getev(GL_SOFTWARE_EXTENSIONS_FORCE),GL_EXT_texture3D) ) 3D textures are a software fallback else if ( extension string contains GL_EXT_texture3D ) 3D textures are hardware accelerated else if ( is_in_list(getev(GL_SOFTWARE_EXTENSIONS_ALLOW),GL_EXT_texture3D) ) 3D textures are a software fallback else if ( advertised OpenGL version = 1.2 ) 3D textures are a software fallback else 3D textures are not supported at all is_in_list() is some self designed function similar to strstr(). strstr() itself wouldn't work because some extensions do represent substrings of others. trust me. ;-) -Alex.
RE: [Dri-devel] Re: Ann: gcc-2.96 compiled snapshots available (I'm going to smack redhat)
Title: RE: [Dri-devel] Re: Ann: gcc-2.96 compiled snapshots available (I'm going to smack redhat) Its c code, so I don't think the version of gcc is that important, what matters is the GLIBC_2.3 symbol, it doesn't show up in the X driver, because it isn't linked against libc, however, the dri portion is. For some bizzare reason, redhat has decided to put a cvs version of glibc in their upcoming distro release, which you are aparently compiling against, the current release version of glibc is 2.2.5, more than 90% of users are probably using this version. This still doesn't make sense to me. So isn't glic-2.3 backwards compatible? I've been using quite alot of RHL 7.2 compiled programs with the new version and had no problems whatsoever. So why do the DRI drivers require specifically version 2.3? Perhaps this is a pickyness of XFree86 module loader. as far as i understood, backwards compatibility means that you can run old programs with the bleeding edge glibc. but vice versa, brand new programs wont run on old glibc systems (including an XFree86 loader that only knows about old glibc). if there is a new symbol in new modules that does not resolve on old XF86 systems then it wont run. Maybe there is a way of just stripping that single symbol and all runs fine then. Its just a wild guess. For my expirience i only tested old modules on new red hat and had no problems with them, so the approch of Jose with the chroot and some previous glibc version will do the job. -Alex.
RE: [Dri-devel] Spam on this list, list email addresses are out in the open.
Title: RE: [Dri-devel] Spam on this list, list email addresses are out in the open. Set ML submission to moderated for non-subscribers and few persons that check the backlog regularily. Further add e.g. a 24 hours timeout (if possible), so that nothing gets stuck unclassified forever. This way the mails can get filtered out and the regular traffic can reach the destinations. I know several other ML systems, e.g. the gnome project, where it works nice. dont let your ML get misused as distribution system the spammers messages. -Alex.
RE: [Dri-devel] ATI Radeon VE QY (AGP) new drivers (personal) problems
Title: RE: [Dri-devel] ATI Radeon VE QY (AGP) new drivers (personal) problems Hi! here is my problem: I was using the drm drivers wich comes with the 2.4.19 kernel (1.1.1), Sounds stable for me, and compatible to XFree86 4.x.x versions. it was workig right exept fo this: (II) RADEON(0): Using 8 MB AGP aperture it looks like it is only using 8Mb and my [grafics board] has 64Mb AGP-Aperture means a special paging circuit in the mainboard(!) chipset that maps pages of memory into a linear PCI bus memory window. The more precise term for the system is GART and its a subset of the AGP specification which also specifies the AGP transfer modes. Enter your bios and tune your APERTURE SIZE e.g. to 8, 16, 32 or 64 MB. It does not hurt if its too big unless you really allocate the space because it must be backed up by existing main memory. A bit bigger than needed by your applications texture demand is okay because this will avoid fragementation of that page rempaping range. Yes, even the gart range memory pool can be used up. Aperture size and grafics memory size are not related in any way. glxgear only gives 480FPS. I would assume 200 FPS is software rendering, but 480 FPS looks more like hardware rendering. (hmm, or a pretty fast CPU) Can you check with glxinfo if Mesa or hardware rendering is running? Check also with /sbin/lsmod if respective kernel modules are active and countercheck in XF86 logfiles if kernel modules init did succeed. Possilby the most recent beta drivers from the CVS repository might give you much better numbers, but i am not really sure about it. I just dont have a URL handy for you for this resource. mysystem: linux2.4.19, XFree86 4.2.1, AMD Athlon XP 1600+, Asus A7v266-e mb, ati radeon 7000 with 64 mb of memory. Plese if you do repley the do it to the dri-devel list so the most expirienced person in your specific subject will be able to answer the questing. Thanks. -Alex.
RE: [Dri-devel] nForce and AGPGART
Title: RE: [Dri-devel] nForce and AGPGART Can you please send the outputs of `lspci -v -xxx` to the list? -Original Message- From: Rene Sepulveda [mailto:[EMAIL PROTECTED]] Sent: Friday, September 27, 2002 08:27 To: [EMAIL PROTECTED] Subject: [Dri-devel] nForce and AGPGART I tried to install a Radeon 8500 on a system with an nForce-based motherboard but I couldn't direct rendering to work because agpgart failed to load: Linux agpgart interface v0.99 (c) Jeff Hartmann agpgart: Maximum main memory to use for agp memory: 816M agpgart: unsupported bridge agpgart: no supported devices found. Is it true that the nForce is unsupported by agpgart or am I doing something wrong? I looked at the agpgart code in the 2.4.19 gentoo kernel and sure enough I saw no references to nForce or Nvidia in the code and in particular no nForce in the agp_bridge_info array. I tried agp_try_unsupported=1 but that didn't help. Thanks, Rene --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] xf86drm.c patch to help FreeBSD's linux compatibility, linux's devfs support.
I'm planing on having DRISUP_BOTH, DRISUP_BSD, DRISUP_LINUX, DRISUP_NONE defined for the 3rd element. I dont like the both thing. The design looks for me rather like a bitfild than an enum... so this would be the solution: (DRISUP_BSD | DRISUP_LINUX) a DRISUP_ALL would make more sense, but the cases where it will apply will not be large, if ever existing. Later something like DRISUPPORTED(bsd,linux,ect...) can be implemented for more OSes. i am in favour of the basic idea to design a standard way for determining what specific chips a driver is capable of. two platforms means portability is mostly solved and its adoption will rise soon. Regards, Alex. --- This sf.net email is sponsored by:ThinkGeek Stuff, things, and much much more. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] Argggg so close with S3 Virge/MX, yet so far...
On Saturday 06 July 2002 20:38, David Willmore wrote: Well, I've been waiting what seems like forever for a driver for my laptop and now there is one! What a happy day! One problem, it's an older Compaq laptop and uses a propriatary chipset (and AGP bridge) so no AGPGART. *do-oh* Suggestions, anyone? Have you tried with AGPGART options agpgart agp_try_unsupported=1? -Dieter Compaq had some in house standard for GART pages implementation. You can find references to this in some third party chipset documentaiton. This means they had a few bitfields where a generic GART driver could retrive some information, e.g. if its a two level GART implementation. I really dont know what sort of chip you do have. Do you have the PCI IDs (including subvendor/device IDs) handy and possibly a dump of the brige registers? Maybe its just a third party ASIC development that was renamed for integration into the compaq systems. If it is a GART capable chipset then it narrows down to just a few vendors. Further hints on model name or a possible windows module for GART support would be of great help in the end. Regards, Alex. PS: i dont mention AGP at all because GART is the thing that always was implemented vendor proprietary - its not a standard! AGP support is highly generic, GART support is not. --- This sf.net email is sponsored by:ThinkGeek Oh, it's good to be a geek. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] Re: [Xpert]glXMakeCurrent dummyContext problem
Meelis Roos wrote: $ glxinfo name of display: localhost:10.0 Xlib: connection to :0.0 refused by server Xlib: Client is not authorized to connect to Server display: localhost:10 screen: 0 direct rendering: No If the display is different from :0.0 (:1.0, remote display, whatever) then GLX initialization tries to connecxt to :0.0 and fails. Sometimes this takes time, depending on user configuration. For example, on my home computer I have to wait quite a long for this :0.0 connect timeout for some reason when running GLX things on :1.0. I have seen this behaviour several times and today I decided to find out what's wrong. i am thinking of something like this for your case: export DISPLAY=localhost:1.0 or something similar like this: glxgears --display=:1.0 thats the way you can launch X programs on a specific desktop from a different X-Server (e.g. trough a VNC session) or even from the console or a remote shell (ssh, telnet, ...). Regards Alex. ...maybe i missed the point here... if you find any typos - they are a free gift. --- This sf.net email is sponsored by:ThinkGeek Oh, it's good to be a geek. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] Capturing debugging info without networking
i would prefer this DRI_DEBUG_DIR=/var/tmp/dri_debug_`date +%Y-%m-%d-%T` so that on sorted dir listings the most recent is always on top since this date is encoded MSB first. (textual month locales wont sort that good at all.) another two things you might want to add: /sbin/lspci -vvv $DRI_DEBUG_DIR/lspci.txt /sbin/lsmod $DRI_DEBUG_DIR/lsmod.txt do you expect this commands beeing executed as root or as a user? you might want to add some suid root detection or a su - query to the script lines. hmm, is there a way to dectect what built in or external modules a specific linux kernel does provide? why are you using for some of the redirections? what about a final bz2 tarball creation? -Original Message- From: Al Tobey [mailto:[EMAIL PROTECTED]] Sent: Tuesday, June 25, 2002 23:39 To: DRI Subject: [Dri-devel] Capturing debugging info without networking Here is a sort of simple shell script that I just thought of that might make people's lives a little easier. Cut paste this into a file (maybe /usr/local/bin/dri_debug.sh) and then add this line to your equivalent of /etc/rc.local: /bin/sh /usr/local/bin/dri_debug.sh to have it run at boot time to save info from the last crash. Otherwise, just run it any old time to get a snapshot of log data. If there's interest, I'll put together a nice rc script that should work on most distros for distribution with the testing binaries. This is just a mock up (I haven't even run it - I hate dog food ;) of what should be a bit more complicated and grab a few more things, but you get the idea. DRI_DEBUG_DIR=/var/tmp/dri_debug_`date +%d-%b-%Y-%T` mkdir $DRI_DEBUG_DIR cp /var/log/XFree86.0.log $DRI_DEBUG_DIR # this should work, but a grep might be better ... tail -5000 /var/log/messages $DRI_DEBUG_DIR/syslog.log cp /etc/X11/XF86Config* $DRI_DEBUG_DIR ls -l /usr/lib/libGL* $DRI_DEBUG_DIR/usr_GLFiles.txt ls -l /usr/X11R6/lib $DRI_DEBUG_DIR/X11R6_libFiles.txt ldd /usr/X11R6/bin/glxgears $DRI_DEBUG_DIR/ldd_glxgears.txt # any other files ... tar -czf $DRI_DEBUG_DIR.tar.gz $DRI_DEBUG_DIR #rm -rf $DRI_DEBUG_DIR It might be nice to patch xinitrc to do this: glxinfo /var/tmp/glxinfo.txt every time so it can be bundled up, too. Then when people start having problems, the list can expect (somewhat) consistent reports. Lemme know what you think. I take no responsibility for the meltdown of your system ;) -Al Tobey This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the Priority Health Information Services Department at (616) 942-0954. --- 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 --- This sf.net email is sponsored by: Jabber Inc. Don't miss the IM event of the season | Special offer for OSDN members! JabberConf 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] Re: Fixed binaries on SF
he using 20020625 snapshot from XFree86.0.log ... (II) RADEON(0): [drm] drmSetBusid failed (7, PCI:1:0:0), Permission denied (EE) RADEON(0): [dri] DRIScreenInit failed. Disabling DRI. ... Huh? Hi might try as root. If it works then something with per user file permissions or sticky bits is odd. other idea: for the odd case of legacy problems i would suspect that there is an API mismatch due to file inconsistency or the drm devices just do have the device file id. (there was a change in that area some time ago.) --- This sf.net email is sponsored by: Jabber Inc. Don't miss the IM event of the season | Special offer for OSDN members! JabberConf 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] Capturing debugging info without networking
some of the current desktop managers has those dial home feature with the fault handler built in. each crash could get sent to the development team if the user likes it. Maybe improved crash logging should get an integral feature of X11 on general platforms (of course embedded folks wont like it). -Original Message- From: Sergey V. Udaltsov [mailto:[EMAIL PROTECTED]] Sent: Wednesday, June 26, 2002 21:23 To: Alexander Stohr Cc: Al Tobey; DRI Subject: RE: [Dri-devel] Capturing debugging info without networking Good boys! Can anyone invent the way to do the same thing with gdb? So on X crash one could get backtrace without remote debugging... Cheers, Sergey --- This sf.net email is sponsored by: Jabber Inc. Don't miss the IM event of the season | Special offer for OSDN members! JabberConf 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] S3 VIRGE DRI in CVS now
If the critical feedback is already big now, then first fix a bit in drivers and then widen the testing audience. A bit I had to study (laws + Savage4 docs). A bit I have to workc. A bit I had to drive my Toyota MR2 Roadster. A bit I had to live. ; ) Feedback is starting to rise. Should I announce the branch on freshmeat? Vale, -max lingua --- 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 --- 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] Re: Compilation
Or you are try out the current closed source drivers for X11 and the ATI FireGL 8700/8800 - they do run on the BUILT BY ATI Radeon 8500 boards as well. The board indicates this compatibility by a PCI Subvendor ID of 0x1002 or ATI. -Original Message- From: Mike A. Harris [mailto:[EMAIL PROTECTED]] Sent: Monday, June 24, 2002 08:31 To: Marc Poulhiès Cc: [EMAIL PROTECTED] Subject: [Dri-devel] Re: Compilation On 23 Jun 2002, Marc Poulhiès wrote: Date: 23 Jun 2002 22:28:14 +0200 From: Marc Poulhiès [EMAIL PROTECTED] To: [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii List-Id: dri-devel.lists.sourceforge.net Subject: Compilation Hi! sorry if this question is very dumb, but i wanted to test the latest dri drivers for my ati radeon 8500 but they wont compile... Here are the messages i get: There are no Radeon 8500 DRI drivers. Not until October-December this year anyway (Q4/2002). You'll have to wait until then. -- Mike A. Harris Shipping/mailing address: OS Systems Engineer 190 Pittsburgh Ave., Sault Ste. Marie, XFree86 maintainer Ontario, Canada, P6C 5B3 Red Hat Inc. http://www.redhat.com ftp://people.redhat.com/mharris --- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel --- 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] Re: Compilation
Hello Alexander! No change to get this going on your partner boards? Even with flashed BIOS? I can get may hands on a 8500LE on top of my dual Athlon 1900+ MP/XP for testing. Thanks, Dieter The partner boards do have individual board features which aren't tested and/or supported by this drivers. Its not possible to support all those third party boardmakers products unless those companys do fund and/or support our local Linux development in some way. Else we would redirect an unkown amount of support queries to ATI phoneline helpdesks for non ATI boards. For now you should consider those Linux drivers are an extra feature which is funded by the own board sales. As someone else wrote, the development of open source drivers is assisted as well by ATI, but it would solve other not so wide spread platforms like DEC alpha CPU or PowerPC CPU in some time frame. The same applies for third party board vendor products on x86 platform. I think you know about the very recent Athlon MP and cache coherency findings. They were addressed by recent information from AMD itself. Due to its urgency, OpenSource and ClosedSource programmers for Linux and X11, got informed about the solutions roughly at the same time. For the ATI FireGL drivers, this means there will be measures and additional notes in upcoming driver releases, e.g. 1.4.0, that will help handling such machine setups. Regards Alex. --- 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] Website [update!]
Hardware - wibble whatever this is. DRI Logo doesnt represent a link to home. it should be for convenience (other highly important things already mentioned by others.) for sake of niceness the sourceforge.net link with logo is missing. The previous design had some headers and footers, i dont think they are required any more to help if the menu bar grafics didnt load, but for the sake of e.g. pure textmode browsers without frames they are still helpful. Further i would like some copyright statment, in the footer, even if the pages are free. Knowing the origin is important as soon as there is at least one mirror site and for people who do print or quote the pages its as well of interest. -Original Message- From: Ian Molton [mailto:[EMAIL PROTECTED]] Sent: Monday, June 24, 2002 18:02 To: [EMAIL PROTECTED] Subject: [Dri-devel] Website [update!] Well, I've backed up the old website (except for the huge snapshots folder. I've also put the shell of the new site up. go to http://dri.sourceforge.net/new_site/ to see it. I'm awaiting some charts and a couple of pages from Liam, which look to become excellent references, and I have yet to hook up some of the links. I'll be doing these tasks shortly, but I'd like to know what y'all think of the new layout? (yes, I know the hardware page isnt there yet ;-) --- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel --- 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] Radeon 7500 lockup
Seriously, the DRI stuff does live in seperate directories, with the sole exception of the 2D driver, many of which have different maintainers in the XFree86 project scope. So there is a strong physical seperation of the DRI code in the XFree86 tree. So, more than the time that takes to merge trees, it would be the sinergy of both projects. (My primarily concern is that the lack of manpower and tight policies of the XFree86 project would drag us down instead of boosting). José Fonseca A merge would pull the plug from that constantly growing fork problem. Having two CVS repository is much different from having one repository with a mainline tree and a crowd of patches against it. A branch and much more a separate CVS does have the habit to develop much on his own unless you go the two-side pain (plus the one that does have the task of merging) of permanently syncing them. Regards Alex. PS: Why not merge all that stuff in BitKeeper or alikes? I dont want to say CVS is outdated, but maybe it can have some advantages if such a merge happens on a new platform. PS2: sorry if my comments are outdated to that respect... ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas - http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] 8500 Drivers
First, I took a look at the current radeon source, but if someone could explain me what the ringbuffer and the freelist are, i think i would at least be able to imagine something of what's supposed to happen. Maybe you should start reading about advanced c programming technics first? (Okay, Pascal will do the job as well.) advanced here means programming with mutexes, semaphores, interrupts, object handles, buffering, chaching, memory management and all that makes up a true multitasking OS. Of course you can still do a good job at open source movement, even if you have only standard c knowledge in the beginning. But i will explain for you below... ringbuffer = fifo alike object in contiguous memory range, written by a pointer an read by a second pointer, the pointers are moving in only one direction and are wrapped at some limit, having both pointer the same value means buffer empty and write pointe one before read pointer means buffer full, most famous representative of ringbuffer is a keyboard buffer, in terms of grafics the buffer is read by the grafics adapter and filled in with commands or data by the host cpu. freelist = (i dont know exactly, not watched that source), maybe here its just a memory manager that contains a list of linked pointers to account chunks of memory that is free for usage in the system, when to free objects are adjancent then they get merged, when there is a memory request that requires less than the object provides then the object is split according to the request, possible applications are GART ranges, mem pools, texture mem, offscreen heap. If you want to understand some particular hardware programming you will be in need for the chip documentation or at least for someone who explains the main concepts of the participating devices that specific area. Regards Alex. ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] g++-3.0 fix for lib/GLU/libnurbs/nurbtess/quicksort.cc
Good fix Felix. I do hate local function prototypes. Its just bad coding style and laziness. Further it shows a critical lack of knowledge for the header file organisation. They are never verified against the implementation by the compiler and might be overseen rather quickly when the function API gets modified. There is only one way of eliminating those flaws: tuning the compiler warnings to a rather verbose level and let the compiler consider them as errors. Just one question: Would you (and the XFree86 and the kernel folks) allow me to rework all your sources at that degree, touching lots of code lines just to let the compiler report a few more warnings? Most of them will relate to constellations that are really not dangerous, and this will possibly unveil not even a single bug at all when compiling, possibly not now and not in any future. Regards AlexS. ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
FW: [Dri-devel] Radeon 7500 + AMD761 Locks machine
oops, should go to the list. -Original Message- From: Alexander Stohr Sent: Thursday, May 16, 2002 01:11 To: 'Dieter Nützel' Subject: RE: [Dri-devel] Radeon 7500 + AMD761 Locks machine I can confirm from own expirience so far... Some 300-350 Watts power supply are required to drive an older Athlon with a grafics board that consumes more power than just the office adapter would need. I found it tightly related to heavy 3D usage peaks. And it often happened already in the first moments when launching some application. But to clarify, its not always the power supply, but sometimes its caused by things like system lockups due to failed bus transfers. -Original Message- From: Dieter Nützel [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 15, 2002 22:04 To: DRI-Devel Cc: Zilvinas Valinskas Subject: Re: [Dri-devel] Radeon 7500 + AMD761 Locks machine On Wednesday 15 May 2002 04:31, Zilvinas Valinskas wrote: [-] Now with 400W ... it is completely gone ... no random lockup because of radeon ... :| GREAT to here. I can see now why random lockups happen given what is loaded inside computer : (all because cheap power block ) YES! MB: KT7A-RAID / Athlon 850Mhz (not overclocked) 4HDD (7400 rpms) (RAID enabled) cdrom Radeon VIVO 64 SB Live! (constantly playing inet radio) Network ... Not that hard. Think about an Athlon TB 1.4 GHz...;-) All VIA based motherboards require no less 300W power supply ... or so. No. Not only VIA. It should read: All (older) Athlon systems.!!! AMD's own, SiS, Ali, nForge and of course Intel (for there P4). There was an intention when AMD gave advice in August '99 (Athlon I release) which power supplies to use. Sorry, in German (taken from http://www.msi-computer.de/) ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] dri and SIS chipset
in the /usr/X11R6/lib/modules/dri/ there is an file called sis_dri.so. Its the OpenGL hardware accelleration module for some SIS chipset. It plugs into the DRI concept when an application does use OpenGL. Do i have to up date this or what ? It should have the same version as the rest of your drivers, e.g. the kernel module or the 2D display driver. How would i go about updating this? Get the respective file and copy it to this location. For the paranoid, restart X11 now. or does this have any thing to do with my problem. I am not familiar with the SIS chipsets, its AGP caps and its overall stability. I cant tell you how useable that driver is for the misc hardware versions. Regards, Alex. ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] Mach64 for ppc xf86-log etc
Please do the following tasks via telnet and report back to the list: - See if there is any application consuming all processor (top). - Copy the Xfree86.0.log to a safe place and post it here. - Check if X is still running or not (ps -A | grep X) and point down it's pid, and if it is do: - do gdb /path/to/your/X pid - get a backtrace with bt and paste to somewhere - quit q - Do the same steps as above with your opengl application. Before attempt to do the above get debug info from the DRM, doing from a X console as root: - rmmod mach64 - insmod mach64 drm_opts=debug - cat /proc/kmsg kmsg.txt After the computer has crashed send that kmsg. So far that i know you can only restart kernel modules if their usage count is zero. This means as long as you are running X or some application (even when X is already down) it wont work. if it looks like the console is responsive, it still can prevent your machine from shutting down because the kernel module wont unload due to some module internal inconsistency or fault. successfully restarting X in such a case is unlikely as well. If i dont have remote access to the box i would just try to issu a vga_reset to et least get a workable screen and analyze the state. Sometimes console switching helps a tiny bit or restarting X (even if it doesnt work) but dont expect much to work, the system is already screwed. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
FW: [Dri-devel] New cards (GPU's) from old card makers? DRI support?
Oops, intended to send this to the list... -Original Message- From: Alexander Stohr Sent: Friday, April 19, 2002 13:54 To: 'Gareth Hughes' Subject: RE: [Dri-devel] New cards (GPU's) from old card makers? DRI support? I really hope not... and at least in with the cards that I may aquire in future I'll surely avoid that that happens. I don't think anyone can answer that question. I know I can't, at any rate. It all depends on how important Linux is to the different vendors. You may not believe and/or like it, but those that take it seriously are probably more likely to release their own drivers, which are more likely to be closed source than open source. I just want to agree. Open Source will only exist in cases where the vendor just cares enough for Linux support to release enough specs but cant or wont care for this himselves. Further the aspects of his intellectual property values must be meet. If the vendor is picky on that then open source will possibly have bad luck. If both are good then its just a matter of OpenSource programmers in the end. Regards, Alex. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] mach64: performanc = f (phys. screen res.)
I recently found out that the 3d performance of the mach64 branch (in terms of glxgears frame rates) is related to the physical screen resolution. I got the following glxgears frame rates with different resolutions: 1152x864: 155.2 fps 1024x768: 165.6 fps 800x600: 209.6 fps 640x480: 229.4 fps 512x384: 218.0 fps 400x300: 235.0 fps I think the default gears window is only some 250x250 in size. It is interesting that there is a decrease in performance from 640x480 to 512x384. 512x384 and 400x300 are defined as double scan equivalents of 1024x768 and 800x600 respectively in my XF86Config. So the CRT refresh seems to play a role in this (I'm don't have a laptop, it's a ATI XPert98 in a desktop PC). I'm wondering whether these effects are a bug or a feature. The RAMDAC shares the memory interface with the rasterizer and the CPU. So the amount of data it transfers can have impact on anything. If you have high resoulutions with big color depth and high refresh rates then are likely to spot bigger impact. This doesnt specifically address the mach64 but any design of that sort. It basically depends on the 2-way memory troughput performance on how a specific card does show reaction on a resolution change. Maybe the mach64 has further areas that play a role than just that. I am just thinking of chip designs that are bound to hsync and vsync waiting or similar might be, but i havent heared the mach64 does depend on that sort. Furhter, surface alignment might play a role, but as gears launches all at the same position so there should be no change untill you change your window manager decoration. Regards Alex. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] mach64: performanc = f (phys. screen res.)
I thought about it again and made a plot of the fps over the pixel clock. This indicates that the different performance is *only* related to the CRT refresh. This is the Octave code I used to generate the plot: modes=[125.00; 115.50; 69.65; 45.80; 57.75; 34.83]; fps =[155.20; 165.20; 209.60; 229.40; 218.00; 235.00]; data=[modes,fps]; gplot data with lines The plot is attached as eps. In other words, the amount of pixeldata that your RAMDAC reads from memory slows your GL rendering down. Natural, just to proof. If you had changed the last but one with the last but two value, then your eps would have looked nicer. Anyways, the numerical sum of both values is at about 270-280 for your setup, so you could assume edges like this: - If turning off ramdac reading totally, then gearls will run with 280 fps. - If you could bring up pixel clock to 280 then any rendering (not only gears) will stop. (whilst the sync cyles a bit might get trough.) Regards Alex. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Mesa3d-dev] Re: [Dri-devel] Mesa software blending
I agree with the you have to read pixels back from the frame buffer and then continue rendering polygons. For a hardware implementation I might agree with the you need to draw more polygons than your hardware has room to store, but only if the hardware implementation decides to perform overdraw rather than fetching the triangles on the fly from AGP memory. You need to agree that current hardware does implement the sheme where some percentage of pixels is drawn multiple times. Its a straigforward hardware design that nicely opens ways for getting the performance with an affordable amount of ASIC design engineering power. I dont assume the current market leaders did choose that way if they did expect to get more performance from the approaches. In the end i am pretty sure that this approach does provide more ways for interesing features and effects than the mentioned one pass rendering would provide. Anyways, the current memory interfaces for the framebuffer memory arent the performance break at all today. Its the features that the applications do demand e.g. n-times texturing. If these one-pass algorithms would be so resource saving, why is there only a single hardware implementation and the respective software solutions are of not much attention? The only reason i can see is, that it does not work as effective and performance increasing. To be honest you must substract the preprocessing time from the rendering gain. And you must expect the adapters not rendering at full speed because its running idle for some time due to CPU reasons. With the rest I disagree. The Kyro, for example, has some high-speed local memory (cache) it uses to hold the pixels for a tile. It can antialias and render translucent scenes without ever blitting the cache to the framebuffer more than once. This is the advantage to tile-based rendering. Since you only need to hold a tile's worth of pixels, you can use smaller high-speed cache. Pixel caches and tiled framebuffers/textures are state of the art for most (if not all) of current engines. Only looking at the Kyro would draw a fals view of the market. Kryo has it too, so its sort of a me too product. But a vendors marketing department will never tell you that it is this way. As far as the reading of pixels from the framebuffer, this is a highly inefficient thing to do, no matter the hardware. If you want a fast application you will not attempt to read from the video card's memory. These operations are always extremely slow. For this there are caches (most often generic for nearly any render unit). And reading is not that different from writing on current RAM designs. Some reading is always working without any noticeable impact on performance, (and its done for a good bunch of applications and features) but if you need much data from framebuffer, than you might notice it. That closer the pixel consuming circuit is to the RAM that better it will work. A CPU is one of the not so good consumers for pixels. I still maintain that immediate mode renderering is an inefficient algorithm designed to favor the use of memory over computations. Hmm, current state of the art is called display list based rendering and its up to date and nicely optimizde despite the concept is an older one. It takes the goods of both worlds. Fast overdrawing rendering into memory and a higher level of primitive preprocessing. With only a single comparision on a preprocessed displaylist you can quickly decide if that display list is in need to be sent to the grafics adapter. Just belive that the performance is only at an optimum level if you are able to take the best of the two worlds - extreme overdraw rendering is neither good for performance, nor is intense geometrical preprocessing on a per frame base a viable way to performance. The hardware industry has found nice ways for combining both of these technologies to provide you the best of both worlds and thus the highes performance. And they are further developing in both of that areas and a few others more. Regards, Alex. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] new Radeon DRI driver binaries not compatible with SuSE
I think i know about that state. Terminating it doesnt work in the end. It does happen to me that way if corrupt the command buffers for the grafics chip. This is either a direct programming error like an inadequate amount of data after a specific command package, an illegal command or some situation where the chip state is not as expected or e.g. two threads made it to use the same buffer at the same time (non atomic/non locking). Or maybe its something not listed here. try running the vga_reset tool before launching X11 again. -Original Message- From: Martin Spott [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 09, 2002 14:39 To: [EMAIL PROTECTED] Subject: Re: [Dri-devel] new Radeon DRI driver binaries not compatible with SuSE I see sudden lockups, mostly on displaying complex structures, i.e. in FlightGear when enabling panel display. This is obviously a graphics card lockup. The picture freezes but I can log into the machine via network. When I restart the X server also the rest of the machine gets locked up and my network connection freezes, Martin. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Mesa3d-dev] RE: [Dri-devel] Re: CPU vs. GPU bandwidths (was: Mesa software blending)
But now think that: you have 8 light sources (specular, highlight, abient nicely mixed), some 3 to 8 clipper planes, an exponentional fog function applied, you are using two sided triangles and of course misc material sepcifications. I suspect that under these conditions, neither does gf3 get its peak 88 million triangles/second. It depends on trying that out. As a typical pipleine design will require each stage to perform as fast as the data does run in, these (mostly scenery static) parameters should apply on the fly with only lengthening the pipe pass trough time but not the highly important data troughput rate. What do you think --- that Nvidia quotes as the peak performance of the card the performance when drawing the computation-intensive triangle, or the simplest one? nope, sureley not. But i assume that pretty much features could be applied without any siginficant performance impact. A typical triangle count (=vertex count) over triangle size diagram for current adapters will show a pretty constant vertex rate for small triangles (limited trough AGP bus or pipeline speed), and an 1/x curve for the bigger triangles (limited in fillrate trough rasterizer speed and framebuffer bandwidth). The overall utilisation peak of any current adapter is at the point where the peak vertex rate line meets the fillrate peak curve. Now you turn on the misc features that you want to use in your specific target and see how that diagram changes. But for a true performance value you are best adviced to ignore such academic curves and get hands on a test suite that matches most of the features that your application does use. Does Conway's Life run faster on GF4 using the stencil buffer algorithm go faster than the best implementation on an x86 processor yet? Stencil buffer? Hmm, maybe accum buffer would work as well or better. Call 4 times a blit with accum/stencil, framebuffer clearn and one times a fill that let the board only draws the the pixels which match the respective accum/stencil value. One site reports that GF2Ultra ran at 16 million cells/second. However, another reports that a 66MHz PPC was able to do 17 million cells/second. So maybe we haven't gotten there yet. Further still before a turing machine implemented in Conway's life running in the stencil buffer emulating x86 code beats the Pentium 9, I guess. Jeff I think a not yet realized life rasterizer, texture or blit operation would perform much better. At least the infrastructure in such a grafics chip would serve the purpose much better than if someone wanted to implement the same in a general purpose CPU. Regards, Alex. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] OT: CPU vs. GPU bandwidths (was: Mesa software blending)
Hey Raystonn, Oh my godness, who fed that trolls. ;-) Lets still assume, you havent had the facts handy (due to your age, education, place of birth or current location) for seeing clear in all the subjects you are trying to adress. I would be much happier if i did feel that you were really working at least with a few of the concepts and tools you are refering to. The web is so big and there is nothing much which will hinder you from getting hands on one after the other, if you really like it. Maybe i am on error with you, and you might want to enlighten me what successful computer projects on earth are a result of your bold mind. (dont exclude computer projects for space crafts.) That is far from the truth - they have internal pipelining and parallelism. Their use of silicon can be optimised to balance the performance of just one single algorithm. You can never do that for a machine that also has to run an OS, word process and run spreadsheets. Modern processors have internal pipelining and parallelism as well. But at a much lower degree. Please understand that a Pentium 4 with only a single 64 bit FPU unit for a 128 bit SSE operand is far away from the performence that a dedicated grafics pipline with some 4 dozends of FPUs can carry out. And some of these FPUs even work in parallel to their neighbourghs... Most of the processing power of today's CPUs go completely unused. One reason more that a dedicated grafics chip with about the same amount of transistors as some CPU (thats almost true today) does perfom better by huge factors than the competing CPU. It is possible to create optimized implementations using Single-Instruction-Multiple-Data (SIMD) instructions of efficient algorithms. As long as the optimized version just improves by only some 30% to 50% (or at maximum some 100%) it will never come close to what grafics chips will do by default. Since memory bandwidth is increasing rapidly,... It is?!? Let's look at the facts: Since 1989, CPU speed has grown by a factor of 70. Over the same period the memory bus has increased by a factor of maybe 6 or so. We have gone from approximately 200MB/s of memory bandwidth (PC66 EDO RAM) to over 3.2GB/s (dual 16-bit RDRAM channels) in the last 5 years. We have over 16 times the memory bandwidth available today than we did just 5 years ago. Available memory bandwidth has been growing more quickly than processor clockspeed lately, No - you are still on error... CPU clock rate growth = 70, (from 33 to 2400) CPU register width growth = 4, (from 32 to 128) CPU pipelining speed increase = 2, (worst case assumption) CPU performance growth total = 560 = 70 * 4 * 2 according to your sample: memory bandwidth total growth = 16 (taken from your numbers) hmm, my 1990 system had some DIL rams with ending -70 and -80 which means the latency in nanoseconds. Some cache RAM already had only some 20 ns. if you assume DDR does have 2,5 nsec today i get a factor of 32. Futhrer assumed a factor of 4 in bus width increase we are still at an overall increase of only 64. nicely considered with some factor of 2 bus clocking optimisations we are still facing only a speed increase of 128 for the RAM whilst the CPU speed increase was determined to have a value of 560. and I do not foresee an end to this any time soon. That doesnt contribute any adavance in the argue. Sorry. On the other hand, the graphics card can use heavily pipelined operations to guarantee that the memory bandwidth is 100% utilised Overutilised in my opinion. Not sure what you want to say with it. Byond 100% there is nothing than saturation. A well tuned system utilizes in its main application case 100% for all units. For the not so common cases one of the units will run at 100% whilst other components are idle at a smaller percentage. The amount of overdraw performed by today's video cards on modern games and applications is incredible. No, its a sign of a bad application design. ;-) And anyways, a good video card will eliminate already 50% or more of the supplied data in early calculation states, especially when the dumb applications does send anything to the adapter. Immediate mode rendering is an inefficient algorithm. Agreed, but you can only efficiently use instant display list rendering if your scenery has a noticeable constant geometry data. Its a question of what you are doing. And its a question of the application. Video cards tend to have extremely well optimized implementations of this inefficient algorithm. I dont feel that you know much about OpenGL and its core design principles. I would recommend you a reading of the red book to get into the subject. You might find out that most of above is in no way a required thing when doing OpenGL based rendering. And you will further see that even most cases the you suppose to be damaging to performance a) wont occure often and b) get nicely eliminated
RE: [Mesa3d-dev] Re: [Dri-devel] Mesa software blending
I don't think so. I haven't noticed a problem with fog in the tunnel demo. So it works for you, doesn't it? Envious. For me, the fog effect does not work. Some time ago, someone (Jose?) even explained that is should not work on mach64 (alpha blending + some other effect?) So my question was whether it should work now or not. No, this won't fix the problem. Mach64 can't do fog and blending at the same time, and the tunnel demo uses blending for the menu. There was some discussion of trying to use software fogging per-vertex when hardware blending is enabled, but no one has implemented it yet. Jose was working on some MMX code that was currently disabled in the Mesa source due to bugs in the coding. So he fixed problems that could not come into effect for your case. With that fix you might spot some speedup with an MMX capable CPU if you are running specific mesa demos on it. Concerning the tunnel demo. As long as fogging is not required (at least i think it is not) for the rendering of the alpha blended help texts and the other informatinal texts, it would be the best if you just disable fogging for drawing these elements. Consider that mode turn-off as a fix for some sub optimal application coding. (I should have a look at that source and check if or why its not alredy done in that demo...) Regards, Alex. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Mesa3d-dev] Re: [Dri-devel] Mesa software blending
Hello Raystonn, sorry, but a dedicated ASIC hardware is always faster. (you are a troll, arent you?) in the straight forward OpenGL case (flat and smooth shading) you can turn on several features in the pixel path and in the geometry pipeline (culling, 8x lighting, clipping) that you wont be able to perform at the same speed with a normal CPU setup. Its not only the bandwidth, its the floating point performance which the grafics chips are capable of by the meance of multiple parallel and dedicated FPU units. For the pixel path, when (multi) texturing is enabled or alpha blending or fogging or somtehing else that does readback (stencil buffer, depth buffer dependent operations, anit aliased lines) then you will spot that a classical CPU and processor system will not perform at its best if doing pixel manipulations of that sort. I think a regular grafics hardware can clean up your framebuffer in a fraction of the time, that a cpu-mainboard pairing can do. Thats the case since the good old IBM VGA from ages ago. And dont tell me an UMA architecture is better in that case. You first have to accept that the RAM DAC is time sharing the same bus system and therefore it permanently consumes bus cycles. But if rasterisation has separate memory with an option for a wider bus, separate chaces and higher clocked memory you will get better performance by design. Regards, Alex. -Original Message- From: Raystonn [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 02, 2002 19:45 To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [Mesa3d-dev] Re: [Dri-devel] Mesa software blending [Resending, fell into last night's black hole it seems.] I am definately all for increasing the performance of the software renderer. Eventually the main system processor will be fast enough to perform all of this without the need for a third party graphics card. The only thing video cards have today that is really better than the main processor is massive amounts of memory bandwidth. Since memory bandwidth is increasing rapidly, I foresee the need for video cards lessening in the future. A properly implemented and optimized software version of a tile-based scene-capture renderer much like that used in Kyro could perform as well as the latest video cards in a year or two. This is what I am dabbling with at the moment. -Raystonn ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
FW: [Dri-devel] Max texture size
Oops, i should better care for sending things to the mailing list address. -Original Message- From: Alexander Stohr Sent: Wednesday, March 27, 2002 22:14 To: 'Leif Delgass' Subject: RE: [Dri-devel] Max texture size No, i dont see problems with that. When the resoultion changes and therefore the memory consumption, all the applications should terminate their screen access, including the OpenGL ones, and then query that maximum values again. bpp and max avail offscreen memory that might apply to your calculations should not change unless modes are switched, so the results are consistent. Let me summarize, the maximum texture level in a multilevel texture mapping is determined by the doulbe square object size of the biggest texture. on linear texture heaps, the plain memory amount makes up the capabilities. (visually on rectangular heaps the biggest texture is left and the smaller levels arrange nestingly on the right half of the buffer) the max level exactly matches the power of 2 that the biggest texture has in dimensions. (assumed that all levels are power of 2 and the smalles is of size 1x1) -Original Message- From: Leif Delgass [mailto:[EMAIL PROTECTED]] Sent: Wednesday, March 27, 2002 21:55 To: Alexander Stohr Subject: RE: [Dri-devel] Max texture size On Wed, 27 Mar 2002, Alexander Stohr wrote: So we'd use mach64Screen-cpp for the calculation instead of a fixed 4 bytes/texel? Then the comparison would be: if mach64Screen-texSize[0] = 2 * mach64Screen-cpp * 1024 * 1024, then MaxTextureLevels = 11 else if mach64Screen-texSize[0] = 2 * mach64Screen-cpp * 512 * 512 , then MaxTextureLevels = 10 else MaxTextureLevels = 9 (256x256) This should apply to Rage128 and Radeon as well. Am I missing something here? Yes, if you have a Radeon with i.e. 128 MB then you might want to use even bigger textures or higher max levels, as long as the renderer can handle them. Some sort of iteration or loop design might turn out to be the best. At least you can specify the lower and upper limits much easier then. Regards, AlexS. Yes, for Radeon you can go with a larger texture (2048x2048 looks like the max from the code, I don't have Radeon specs), I was thinking in terms of mach64 which has a max. size of 1024x1024. But do you see any problem with the basic idea in terms of using the screen bit depth? Also, the first '2' should probably be MaxTextureUnits for cards that have more than two texture units implemented, right? -- Leif Delgass http://www.retinalburn.net ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] glSamplePass missing in libGL.so (only glSamplePassARB available)
just a quick guess since i am not aware of that specific function... (assumed) its an extension to the OpenGL 1.x standard. extension names arent most often exported by standard lib GL as symbols but only via the get by name method. you might want to have a look at the respective OpenGL specs now. -Original Message- From: Andreas Stenglein [mailto:[EMAIL PROTECTED]] Sent: Wednesday, March 20, 2002 14:32 To: [EMAIL PROTECTED] Subject: [Dri-devel] glSamplePass missing in libGL.so (only glSamplePassARB available) Hello! just discoverd that (in my) libGL.so theres no glSamplePass symbol available. its build from today (2002-03-20) DRI-trunk-code. And its not available in the tcl-0-0-branch, too. strings libGL.so | grep glSamplePass glSamplePassARB regards, Andreas [EMAIL PROTECTED] ___ 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] Reminder: IRC meeting log history - some logs are still missing
At http://dri.sourceforge.net/IRC-logs/ you will find these chat logs online: 20020121.txt22-Jan-2002 04:0062k 20020128.txt04-Feb-2002 11:0246k 20020204.txt07-Feb-2002 05:3441k 20020218.txt26-Feb-2002 16:2731k 20020225.txt26-Feb-2002 16:2737k I have heared that logs of the most recent chats do exist, but they are not yet submitted to the folks with access rights (i dont have developer rights on the dri project at SourceForge). But i think Michael (or some other developer) would care for this subject if you sent them the missing chatlogs via direct mail. Regards, Alex. -Original Message- From: Michel Dänzer [mailto:[EMAIL PROTECTED]] I moved all logs to http://dri.sourceforge.net/IRC-logs/ and added a FAQ entry about this. PS: Frank, the FAQ entries containing logs directly didn't work out so good because they are treated as HTML. Please remove them. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] PIO New mach64 snapshot
On 2002.03.13 19:21 Brian Paul wrote: ... But if the Mach64 chip is the bottleneck, no amount of (conventional) driver optimization will improve the results. It _really_ depends on the particular application. -Brian That means if the triangles are big then pretty few to do with CPU. If you have display lists and much vertex data, then a TCL might give you big advantage. For texturing its advantagoues if the hardware is driven to do multitexturing. Performance optimisation is a rather individual subject. Some applications do never benefit from a particular optimisation. This is something that intrigues me most for some time now. I get a little more than 10 fps on UT with the mach64 driver as it is (just MMIO), but I get about 20 steady fps with software rendering on my P3 Celeron 700Mhz. I can not understand how come this can be. Even though there are a lot of artifacts in the sw rendering, it has a much nicer global appearance. Is this the kind of performance that one can expect from a PIO only card (I'm thinking of tdfx for example here)? If you want so see specific perfomance, you should try glperf. Thats one of the important feedbacks on your specific works. Regards, Alex. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] Radeon TEX2
Would anyone know what was wrong with support for Radeon third texture unit ? The problem is that Mesa 3.4 only supported two texture units (there were some bitfields that didn't have room for more bits). In Mesa 3.5 and later the limit is eight. It shouldn't be hard to enable the third unit on the mesa-4-0 branch. Did XFree86 4.2.0 ship with 3.4 or 3.5 ? according to xc/extras/Mesa/src/config.h and the contained statment #define MAX_TEXTURE_UNITS 2 i would say the file is still the same as for Mesa 3.4 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] Pseudo DMA?
PIO = Programmable IO. Registers that are possibly in x86 IO address space or PCI config space. Today these are just memory mapped registers where the CPU has direct access. DMA = DirectMemoryAccess. Typically an engine on a chip which trasnfers data forth and back. It needs initialisation via some sort of register programming or other meance. Other terms might be specific to individual chipsets, chipset vendors or software projects. Some other keywords are just subsets of special variants of the above. (AGP transfers are just a special case of a DMA.) ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] chown /dev/dri/card0, system crashes
It's puzzling that chown-chmod would have any baleful effect. With a plain file, once you've opened it you can monkey with the inode all you want and the filehandle remains valid, and similarly with devfs the various device inodes (/dev/misc/psaux, modem TTY, etc.) can be chowned even if, in the case of the mouse, the X-server has it open. At least the kernel module for an OpenGL accellerated card is opened multiple times. A few times when the xserver and the window manager initializes and a few more time for each application that (dynamically) links against the OpenGL lib. So changing file permissions at runtime does affect newly started programs. So you do have multiple clients where some of them must have only user permission. A group based access rights management system is a nice thing if your design is okay. E.g.: - user = group with no X11, no OpenGL - video = group with X11, but no OpenGL - opengl = group with no X11, but OpenGL (thats just my suggestion for the paranoid, typically its caps are included in video) - root = the systems wildcard group A normal user can be made capable of X11 and OpenGL usage by adminstration so that he further joins the respective groups. Alex. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] Radeon 8500 FAQ was: 2 second question: radeon TL
Does anyone have any news on support for iDCT and Motion-Compensation or any of the video related features of the radeons? Do the reference drivers from ATi have anything for these features? Just curious. Thanks, Alex So far i do know, there should be a solution for your problem in the upcoming code. I am not sure if it is open source, but from a clients view its a solution. You might have missed this posting to the list which tells about some other solutions for the 8500 model: -Original Message- From: Vladimir Dergachev [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 30, 2002 03:01 To: Jose Fonseca Cc: dri-devel; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [Dri-devel] Radeon 8500 FAQ was: 2 second question: radeon TL [...] Code for TV-in support for All-in-Wonder 8500DV is now available from http://gatos.sf.net/ (4.2.0 dash 8 binaries). Vladimir Dergachev ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] via kt266a and the Radeon 8500 (QL)
I have a Shuttle AK31 Rev3 motherboard (Athlon XP 1800 cpu) and am trying to get XWindows working. The one thing that sticks out to me is that, with the 2.4.16 kernel, the agpgart driver says the chipset is a KT266 (but not KT266A), but the drm driver says the chipset is a KT133. as root tryout lspci with various options (-v, -vvv, -x) and watch for the vendor/device ids of your chipset. according to www.yourvote.com/pci/ the mentioned chipsets are: 0x1106:0x3099 KT266 0x1106:0x KT266A (possibly only differs in chip revision from previous) 0x1106:0x0305 KT133/KM133 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] agp: what if memory is fragmented?
From: Philip Brown [mailto:[EMAIL PROTECTED]] I thought that was just from the perspective of the graphics card. A GART memory mapping is a memory range that is visible from the grafics card (if on AGP socket) and from the CPU (or CPUs). The GART memory area is looking just as a PCI card that has mapped some amount of memory to the bus. Its a linear chung of memory in terms of the bus scope and therefore has a physical base address and its range is contiguous on the bus. The grafics card simply uses physical adressing. The CPU muss call the OS to do a remap on those physical range, as it has to do for any other sort of PCI adapter memory. But you are saying that ALL AGP supporting motherboards will remap their aperture range, both for the graphics card, AND the cpu? The motherboard chipset do remap a bunch of individual pages into a single GART memory area. Its view is independent and seperate from the regular location of the main memory, there is no overlapping. GART means an aditional view of the same with the advantage of getting memory contiguous for the grafics adapter, even if several could handle fragmentation without that unit. (the CPU already has a sufficient paging unit.) In which case... doesnt that screw up the OS considerably, to suddenly have a large chunk of memory change its apparent contents? :-/ If you have multiprocessing, a grafics co-processor, a busmaster or a cpu-external memory manager, then you must flus CPU read or write caches at certain points of modifications in the sub system. I dont know of any kernel routines under solaris that tell the kernel, Stop using this specific physical address range now: I'm going to take it over You first allocate pages in main memory before starting to remap them via GART. After use you have to do this in the reverse direction. Also.. seems like if you have a system that has a large amount of memory, you would then lose twice the amount of memory you allocate, since a previously usable chunk of memory now gets shadowed to another section of memory. You have to mark the memory as used. But its only a single location, so this single memory is useable for exactly one purpose only. Its single but shared, multiple visible, magically mirrored, purple-dotted memory. The only thing that you need in advance is a memory manager, that tracks which ranges of the GART range are used and which are free. Yeuk. I thought you are called Philip. :-) Regards Alex. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] agp: what if memory is fragmented?
The GART is the paging unit of the AGP system. It deals nicely with fragmented chunks of page sized memory chunks. So you only need some sort of memory allocation and a way to determine eachs pages physical adress to use it for those GART purposes. You just need to ensure that your memory is permanent, which means its neither moved around in physical memory nor swapped to harddisk. And you can have some 2GB gart range whilst you only have a few 100 MB real physical ram in your machine. The idea is to provide as much linearly rearanged memory space so that all your one or two gart clients do have enough linear space to remap to. Regards Alex. -Original Message- From: Philip Brown [mailto:[EMAIL PROTECTED]] Sent: Saturday, December 22, 2001 01:06 To: [EMAIL PROTECTED] Subject: [Dri-devel] agp: what if memory is fragmented? Sorry if this is repeat: haven't seen my original show up in 12 hours. I have a question about what if physical memory is fragmented? The AGIPIOC_ALLOC call returns a 'physical' address. This implies that the ALLOC is a single contiguous chunk of physical memory. Right? However, I cant imagine that it is easy to guarantee 64 megs of contiguous physical RAM allocation. So something seems wrong with my assumption. I've looked at the bsd AGP source, and it uses malloc(), and some fancy bsd magic that I dont understand. Similarly, I do not understand the linux page allocation stuff at all. So, what should be the behaviour of my agp implementation, if contiguous physical memory is not available? I would think it should not be neccessary: thats why the GATT exists, after all?! ___ 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
RE: [Dri-devel] agp GATT table specification
From: Philip Brown [mailto:[EMAIL PROTECTED]] On Mon, Dec 17, 2001 at 10:52:04PM +0100, Alexander Stohr wrote: ... Try this page: http://developer.intel.com/design/chipsets/datashts/index.htm I found what seems to be the only document relevant to my AGP programming issue, 440BX AGPset: 82443BX Host Bridge/Controller Datasheet which is http://developer.intel.com/design/chipsets/datashts/29063301.pdf of which I eyeball-scanned through its 132 pages (skipping the electrical signals section) and while I saw mention of the function of the GATT, nowhere did I see specification of the FORMAT of the GATT. arrg. exactly this i meant and this i remembered about the documentation. and if it doesnt show you all those stuff - go to AMD because they do nicely explain their two level GART system. It helped me a lot to get finally familiar with the topic. but how does learning how to program AMD hardware, help me to program the Intel 82443 hardware that I actually have in my possesion? :-/ Yes, my suggestion sounds weired, but isn't. AMD is categories better in explaining the table structure of the terminal GATT tables - the principle meaning of the bits is identical to those that Intel does use. so you can understand the agpgart programming of the intel chipsets by having read the AMD documentation. just keep in mind that intel does not have that intermediate level of a gatt table directory in its main memory. regards, Alex. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] SIS 630
please visit http://www.sis.com/support/driver/linux.htm in general most chips are supported since XFree86 3.3.6 which is required to run their Linux drivers. as far as i can see there, XFree86 4.0a is a requirement (we are currently apporaching X4.2.0) for their 630 / 540 family while running TV-out or LCD. and they are pointing out to http://sss.wuwe.de/XSuSE for a few other drivers that will run on nearly any current Linux distribution. -Original Message- From: S. Ancelot [mailto:[EMAIL PROTECTED]] Sent: Monday, December 17, 2001 09:43 To: DRI-Devel Subject: [Dri-devel] SIS 630 Hi, Are you planning to work on sis 630 chipset ? Bye steph ___ 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
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] gl extensions on/off
Make the enable/disable configurable by an environment variable, like
so:
if ( getenv( LIBGL_DISABLE_MULTITEXTURE ) ) {
gl_extensions_disable( ctx, GL_ARB_multitexture );
}
if ( getenv( LIBGL_ENABLE_TEXTURE_ENV_ADD ) ) {
gl_extensions_enable( ctx, GL_EXT_texture_env_add );
gl_extensions_enable( ctx, GL_ARB_texture_env_add );
}
Then, a user/app can just do something equivalent to:
export LIBGL_DISABLE_MULTITEXTURE=1
./my_app
And you're done. Variable naming left as an exercise for the user.
-- Gareth
Extensions do get detected by browsing a lengthy string.
Entry point adresses are retrived via a single GL API call.
Extensions constants and alikes simply get used and
will possibly get hounoured by the misc GL calls.
Therefore i would call this hide and reveal in the first row
when some intermediate layer does remove or add
the repsective strings or bases addresses.
Regards, Alex.
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] First experience with binary shapshot: part 3, success
BTW - I found the matter of problem. I have 8M video RAM. And use resolution 1280x1024 (I have LCD so lower resolutions look bad). Even in 16bpp, all buffers take almost 8M - so only 192K remains for textures (actually, on 32bpp the server does not start at all). When I experimentally changed resolution to 800x600 (giving ~5M video RAM for textures) - some textures appeared (but not all - for example, half-life and celestia are still not working). rough estimation: 800 pixels/line x 600 lines x 2 byte/pixel x 2 buffers = 1,9 MB You should expect to have less than 6 MB for textures. (some video memory might be occupied for other purposes like an OpenGL depth buffer, stipple patterns, icons or other objects.) So you observations meet the state that has to be expected. So my question is - will at some point driver use system RAM for buffers and/or textures etc? I thought AGP technology can help here. Correct me if I am wrong. i dont know those specifics driver's state. AGP means two things: - high speed transfers (AGP 1x, 2x, 4x, sidebanding, fast writes, ...) - a paging logic that does provide consecutive page ranges (GART) built upon the systems main memory presented to CPU and grafics. Those Grafics Aperture Range Table system just creates an un-scrambled alias view of the main memory that typcially portraits parts of CPU paging. The first is often simply a question of switching on a few bits in the northbridge and the grafics controller. The location of the related bits in the integrated circuts do follow a standard. The second thing was implemented because Intel(?) thougt that it was a bad idea to have grafics adapters that are able to access scattered pages from anywhere in the system memory (even if most vendors already hat respective logic due to their PCI designs). So Intel required all mainboard chipset vendors to add paging shemes that were already present in CPU and grafics chips. Concerning your comment on texture organisation and AGP i've to comment, its just a question of program code in the driver. Anytime a texture is used, it is best to have it on the grafics adapter. As long as there is enough memory anything is fast. You best compare it to swapping - anytime you use something that is not present, the system hast to reload it with some timing penalty. In worst case you will trash and reload anything on any single frame, in worsest case you will do this multiple times. Having not enough memory is a big performance issue. Having a too dumb texture manager could be slowing down as well. In short words - the texture manager in your driver doesnt look like he is using all availabel resources for the purpose. BTW, geometry data and screen-memory blits should be able to use the GART paged memory pool as well and the high speed AGP bus protocolls as well. Regards Alex. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] AGP and DRI
From: Thomas Dodd [mailto:[EMAIL PROTECTED]] How do I speed up AGP? It looks to be in 1x mode, not 2x. start X11 and respective driver. then login as root and tryout this: /sbin/lspci - | less then you will spot capabilites for AGP on host bridge and on grafics adapter. See AGP[+/-], SBA[+/-] and Rate=x[1/2/4] on the line with Command: - its the current settings. The Status: is the overall caps of your respective configuration, but the AGP inventor didnt seem to be a friend of expressive names. Your box will only be able to drive the speeds and modes that both devices do support. Maybe you will get a bit more information if you look into the AGPGART module code - oh, i think i've seen a few typos concerning AMD there recently. They are at least in 2.4.16 kernel. Regards Alex. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
