Re: [Dri-devel] Re: Ring lockups on mach64
On 2002.06.12 03:49 Leif Delgass wrote: On Tue, 11 Jun 2002, José Fonseca wrote: ... Please, let's not discuss this further. I think we both agree that using a variable is the best wat to go, isn't it? Each and every processor cycle must be precisely documented and accounted for! The lives of rocket-launcher toting space marines depend on our attention to detail! I've clamped onto the throat of this bit of code like a mad dog and will continue to shake it around while foam dribbles from the corners of my mouth long after it's dead. Ahem, ... ok I'm back now, I think I blacked-out for a minute there. :-) Anyway, I just think that in any case it would be better if we only enable bus mastering on idle (if things are going well, an active engine should be the common case). If we do that I don't think it's really a big deal to have the extra writes. The writes could be conditional on a read or we could use a variable instead, but I'm not sure it's worth it and it could be error prone. Now that I think about it, there's an added bit of security and safety in making sure that the block 1 registers are enabled and that src_cntl is set for gui-mastering and FIFO synchronization before starting a new DMA pass. It would probably help performance in general to find ways to reduce the number of DMA restarts we do also. Without doubt. I hope that by joining the state buffers, by speeding up the vertex buffer construction, and (if we don't manage to increase the buffer size on the client side) hold the buffers a little more on the kernel to achieve the same effect we will then overcome this. btw, as I tried to indicate above, I can be a bit of an obstinate bugger sometimes and I'm often just thinking out loud. You might want to have a salt shaker at hand and administer a grain or two when you read my posts. 8-~ (that's me foaming at the mouth). That's ok! I'm not too far behind you! ... Oh.. I didn't had that impression... But even with that restriction, they are a lot smaller than I would expect. I would expect that OpenGL applications made less state changes than that... Changing textures is one example, and I'd imagine that happens fairly often. I should point out that a primitive won't be split across multiple vertex buffers, so that can leave some unused space as well. As you mentioned, we're going to have to revisit vertex buffers at some point in any case, both for performance and security. BTW, last time I had to boot Windows (against my will, of course), I did a quake3 timedemo. On my laptop, the current dri branch is only behind by ~4fps w/ vertex lighting and 2fps w/ lightmap lighting (approx. 82% and 87% of performance in Windows respectively). I'd say we're making good progress. My goal is Indeed! Especially attending that we know that there are several optimization to do yet. to try to at least match the Windows driver, but with a more secure implementation. Me too! Ok. Enough of talk and back to coding..! José Fonseca ___ Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] FREE VIVID DVD
Title: alpha Future DVD Absolutely Free!!! 3 hrs! The Porn Star Edition! Future Works Interactive Demo Disk absolutely FREE! No purchase necessary! CLICK HERE Best Selling New Celebrity DVD VHS: Trench's Naturally Naughty Porno Movie!!! RAP STAR TURNS HARDCORE PORN STAR! Trench of 'Naughty By Nature' goes Hardcore Destined to be the top-selling adult video of 2002. featuring hot single, Icons! Porn Star Janine Motley Crue's Vince Neil: The Biggest Scandal Since Pam Tommy Lee! The tape you have been waiting five years to see! Janine's first boy girl scene ever with Motley Crue's front man, Vince Neil. As you all know, Janine is the biggest star in adult entertainment and up to this point has only been seen in girl/girl films. Now you will see Janine with a man for the first time with beautiful Hawaii as the tropical background. It doesn't get any hotter than this! It's the REAL thing! CLICK HERE This email was sent to you by the Internet Marketing LLC, 1601 NW 97th Ave, SJO3016, Miami FL 33102. This email cannot be considered spam as it was sent in compliance with all existing and proposed email legislation. If you wish to be removed from this mailing, please click here
[Dri-devel] Re: tcl branch merge
On Tue, 11 Jun 2002, Keith Whitwell wrote: Date: Tue, 11 Jun 2002 10:56:16 +0100 From: Keith Whitwell [EMAIL PROTECTED] To: dri-devel [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii; format=flowed List-Id: dri-devel.lists.sourceforge.net Subject: tcl branch merge Although we still have a couple of bugs a lockup on the tcl branch, the situation is in general better than what's on the trunk I'd like to get that code merged now. This will also help get the 8500 branch started. Anyone with any objections should speak up now. For God sake, nobody speak up! ;o) -- 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
Re: [Dri-devel] Matrox G400/450 PCI support
On Mon, Jun 10, 2002 at 07:37:19PM +0100, José Fonseca wrote: On 2002.06.10 18:32 Ville Syrjälä wrote: Here's my understanding of the situation. Someone more enlightened should correct me if I'm wrong. On Mon, Jun 10, 2002 at 04:22:11PM +, Gareth Knight wrote: I am interested in adding DRI support for an Algorithmics P6064 mips development board. I already have the standard X server working OK ... This might be nasty as the card doesn't do scatter-gather DMA. You'd need a physically contiguous chunk of memory which the Linux kernel can't guarantee. I'm not sure how much memory the DMA buffers require. Putting textures to PCI memory might be useless speedwise, but maybe the driver would be cleaner as the card would fetch the textures by itself so the driver wouldn't have to swap them constatly. utah-glx required the user to permanently steal memory with the kernel mem= option. This approach would also mess up mtrr setup. I can think of one nice advantage: It would work on every card from G200 to G550. People with AGP cards could also test it so you'd have lots of testers. I'm not sure about the Matrox design, but in the absence of AGP and PCI scatter-gather DMA, generally a card will only allow to have textures on the onboard memory. This it's what happens on the 3DFX, Gamma, and Mach64 drivers when handling the PCI versions. This is also why you don't find PCI cards with so little memory as the AGP counterparts - they can't rely on the system memory to fill in the rest.. Well I'm not sure but the the DSTORG (destination origin) register has one bit to specify the location (card memory or system memory) and one bit for access type (PCI or AGP). DSTORG must be initialized for all graphics operations. So I'm thinking the card should be able operate on all types of memory and even back and depth buffers can reside in system memory. I think utah-glx did this even before AGP support was added. -- Ville Syrjälä [EMAIL PROTECTED] http://www.sci.fi/~syrjala/ ___ 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] tcl branch merge
Keith Whitwell wrote: Although we still have a couple of bugs a lockup on the tcl branch, the situation is in general better than what's on the trunk I'd like to get that code merged now. This will also help get the 8500 branch started. OK. It's merged. Keith ___ 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] tcl branch merge
On 2002.06.12 17:01 Keith Whitwell wrote: Keith Whitwell wrote: Although we still have a couple of bugs a lockup on the tcl branch, the situation is in general better than what's on the trunk I'd like to get that code merged now. This will also help get the 8500 branch started. OK. It's merged. Keith Keith, does this mean that the tcl-0-0-branch is now closed and that I can stop the tcl-0-0-branch snapshots (and putting a README to explain the change), or will work pursue on that branch? José Fonseca ___ 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] tcl branch merge
José Fonseca wrote: On 2002.06.12 17:01 Keith Whitwell wrote: Keith Whitwell wrote: Although we still have a couple of bugs a lockup on the tcl branch, the situation is in general better than what's on the trunk I'd like to get that code merged now. This will also help get the 8500 branch started. OK. It's merged. Keith Keith, does this mean that the tcl-0-0-branch is now closed and that I can stop the tcl-0-0-branch snapshots (and putting a README to explain the change), or will work pursue on that branch? It's closed. New (major) development will open up on a new branch, but for now bugfixes and small development tasks can occur on the trunk. Keith ___ Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] tuxkart, and bug reports..
Two quick questions :-) First, can anyone tell me if the issues with tuxkart and the Radeon driver from the TCL branch (well, now the trunk) have been fixed? Secondly, does anyone regularly go through the bug reports on sourceforge? There are a huge number of bug reports, some from over two years ago, that should probably be closed :-) Adam ___ 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] tuxkart, and bug reports..
On Wed, Jun 12, 2002 at 12:57:37PM -0400, Adam K Kirchhoff wrote: Two quick questions :-) First, can anyone tell me if the issues with tuxkart and the Radeon driver from the TCL branch (well, now the trunk) have been fixed? Keith fixed a problem with line loops that was causing crashes. It now works for me (more importantly for the 3yo who actually wants to play ita) It still crashes for Keith (at least as of Monday). -- Michael. ___ 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] tuxkart, and bug reports..
On 2002.06.12 17:57 Adam K Kirchhoff wrote: Two quick questions :-) First, can anyone tell me if the issues with tuxkart and the Radeon driver from the TCL branch (well, now the trunk) have been fixed? Secondly, does anyone regularly go through the bug reports on sourceforge? There are a huge number of bug reports, some from over two years ago, that should probably be closed :-) Adam I offered myself to do this on my spare time sometime ago, but so far I just handled a handfull of bugs (more recent ones). I think that there are two things that we must address to really solve this situation: - First, and more important, the current DRI developers must commit themselves to give answers to the bug reports. This applies not only to the SF bug report pages, but also to those made via the dri-users mailing list (where many questions are left unanswered..). - Second, we must agree on policy to clear old reports so that we can make a fresh start from now. Without these two items fullfiled any thing that we may do now regarding this will be doomed to failure, IMHO. José Fonseca ___ 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] tuxkart, and bug reports..
José Fonseca wrote: On 2002.06.12 17:57 Adam K Kirchhoff wrote: Two quick questions :-) First, can anyone tell me if the issues with tuxkart and the Radeon driver from the TCL branch (well, now the trunk) have been fixed? Secondly, does anyone regularly go through the bug reports on sourceforge? There are a huge number of bug reports, some from over two years ago, that should probably be closed :-) Adam I offered myself to do this on my spare time sometime ago, but so far I just handled a handfull of bugs (more recent ones). I think that there are two things that we must address to really solve this situation: - First, and more important, the current DRI developers must commit themselves to give answers to the bug reports. This applies not only to the SF bug report pages, but also to those made via the dri-users mailing list (where many questions are left unanswered..). - Second, we must agree on policy to clear old reports so that we can make a fresh start from now. Without these two items fullfiled any thing that we may do now regarding this will be doomed to failure, IMHO. I'm just in general not a big fan of the bug tracker. I've got a bunch of bugs that I can choose from at any time without having to go through some web form that requires me to log in and wait for slow queries. It doesn't give *me* anything. It is in some ways counter-productive. People expect putting a report in there to have an effect, but it's actually less interactive than email, harder to get correct details (like half the reports are from Nobody, for instance), harder to find out the real problem. I actually think it should be disabled, destroyed, dismembered. Keith ___ 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] tuxkart, and bug reports..
José Fonseca wrote: On 2002.06.12 17:57 Adam K Kirchhoff wrote: Two quick questions :-) First, can anyone tell me if the issues with tuxkart and the Radeon driver from the TCL branch (well, now the trunk) have been fixed? Secondly, does anyone regularly go through the bug reports on sourceforge? There are a huge number of bug reports, some from over two years ago, that should probably be closed :-) Adam I offered myself to do this on my spare time sometime ago, but so far I just handled a handfull of bugs (more recent ones). I think that there are two things that we must address to really solve this situation: - First, and more important, the current DRI developers must commit themselves to give answers to the bug reports. This applies not only to the SF bug report pages, but also to those made via the dri-users mailing list (where many questions are left unanswered..). The dri-users list was founded on the idea that there might be a class of 'power users' out there who would altruistically help newbies get their setup working so that 'real developers' could concentrate on loftier ideas. That class of power users haven't really emerged, if anything it is the power users who are crying for help in the blackness of dri-users, as everyone else just sucks whatever comes with their distro. Again - I think the people on dri-users would be better off just posting to dri-devel. As it looks like we've got to monitor both lists, why bother having a second list? I know I give less attention to posts with [dri-users] than [dri-devel] -- perhaps I think that people posting there will never do any development, so I won't be repayed by spending my time on them. Shut it down, let them post on dri-devel. Keith ___ 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] tuxkart, and bug reports..
On 2002.06.12 18:42 Keith Whitwell wrote: ... I'm just in general not a big fan of the bug tracker. I've got a bunch of bugs that I can choose from at any time without having to go through some web form that requires me to log in and wait for slow queries. It doesn't give *me* anything. The SF bug tracker is not as pratical as, e.g., bugzilla, not even close... The main advantages of having a bug tracking system is that users can search for duplicate problems, and that developers can know which bugs are still unsolved. But with the current state of affairs neither actually verifies! It is in some ways counter-productive. People expect putting a report in there to have an effect, but it's actually less interactive than email, harder to get correct details (like half the reports are from Nobody, for instance), harder to find out the real problem. I also felt the same when I tried to answer to some bug reports. It does get in the way... I actually think it should be disabled, destroyed, dismembered. If nobody else is paying attention to the SF bugtrack system, then we should really close it. (Personally, I think that it even may be the best to do.) But then more developers should equally subscribe to the dri-users mailing list and give answers to the user's problems there... José Fonseca ___ 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] tuxkart, and bug reports..
On 2002.06.12 18:49 Keith Whitwell wrote: ... I totally disagree here... The dri-users list was founded on the idea that there might be a class of 'power users' out there who would altruistically help newbies get their setup working so that 'real developers' could concentrate on loftier ideas. That would be indeed nice, but when that doesn't happen I think we should give them a help. If the developers were the only consumers of the the DRI drivers, then why bothering having a webpage, user FAQs, user manuals, users installation guides, etc.? (Unless that's only to catch more developers..) That class of power users haven't really emerged, if anything it is the power users who are crying for help in the blackness of dri-users, as everyone else just sucks whatever comes with their distro. I noticed several times that users do answer to other users when they know the answer. It seems that most of that class of power users has migrated to dri-devel, by force of the circunstances, i.e., because it was there where all developers where... Again - I think the people on dri-users would be better off just posting to dri-devel. As it looks like we've got to monitor both lists, why bother having a second list? I know I give less attention to posts with To separate the development issues from, .e.g, installation problems. I personally wouldn't like to have my dri-devel mbox full with cryies for help - if that happened I effectively would make my procmail seperate those into another mbox. In theory, dri-devel should be mainly for communication between all developers and beta-testers. The dri-users should be for everybody else. This is what I see in many other projects and it works quite well. [dri-users] than [dri-devel] -- perhaps I think that people posting there will never do any development, so I won't be repayed by spending my time on them. So if they post to dri-devel then somehow they are qualified as developers and will actually do anything!? Shut it down, let them post on dri-devel. Yeah! Let's burn Rome! ;o) Keith I personally think we shouldn't do this, but I'll go for what the majority decides - after all it's what's the majority will do in the end that will really matter. So, speak up now, or forever remain quiet... José Fonseca ___ 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] tuxkart, and bug reports..
On 2002.06.12 19:31 Keith Whitwell wrote: José Fonseca wrote: ... To separate the development issues from, .e.g, installation problems. I personally wouldn't like to have my dri-devel mbox full with cryies for help - if that happened I effectively would make my procmail seperate those into another mbox. Yes, like all that mach64 stuff... (big smilie) Hey! :o That's really insensitive of you... it hit right on the heart! :-) I also put up with all that radeon stuff! (I even read some of it.. what a heresy!:) ... José Fonseca ___ 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] Understanding the internals of a X11/OpenGL Based Program (Using 3D Direct Rendering)
Howzit Jens? 3 Parts to this email. 1.) MK II: _ \ +-+ | | X11/OpenGL Based Application | | | (Using 3D Direct Rendering) | | +-+ | | || V V| +--+ ++ | | OpenGL Library | | XLib | | +--+ ++ | | | | | | | | V | | Application | | +-+ | |--User | | | GLXLib | | |Process | | +-+ | | V | | | | | +-+ V V | | | | OpenGL| ++ | | | | Renderer | | DRILib | | | | +-+ ++ | | | || | | | | | |V V V V V | | +-+ +-+ | | | DRM Lib | | Protocol Encode | | | +-+ +-+ | || || _/ VV VV MMIO IOCTL SHM X Transport I would say in the most common case (single thread, single 3D context) there is only one arrow between the application and a combined Xlib/OpenGL box. This single arrow can be thought of as the primary system:display.screen connection, to use X11 DISPLAY semanitics. Which is the equivilent to the top two arrows in this diagram. OpenGL Lib XLib are just shown seperately. 2.) One thing that I would like to be able to show is, when you have one line going into a box and two lines coming from it, is a branch occuring or is it an either or situation. ie a choice is made and only one path is taken. It depends. There are a large number of actual entry points in each of this libraries. Some entry points may never pass data along. Others may use one or both of the paths. Doesn't it just. But it worked out ok for the X Server internals so I'd like to do it here. I've attached the latest WIP of control_flow.png to help show this. I did *not* receive an attachment. But you've seen it now... RM = Resource Management or = 1 of these 2 paths are followed = both of these 2 paths are followed 2D = 2D commands data 3D = 3D commands data lines in columns indicate individual paths while, lines not in columns are agregations of paths. eg's in my bit of exploded ascii art and the X Server. This becomes somewhat of an issue when you have multiple line entering and leaving a box, so if the lines should match up and don't or vice versa - let me know. I'll probably understand this question better after I see your WIP. Yup it's all part of the same question. 3.) DRMLib whats the differnce between the one in the X Server and the one in the 3DDRP? They both talk to Kernel SAREA (SHM IOCTL). Functionally they are identical, i.e. the same source code. The only distinction, and it's not critical to the diagram, is the DRMLib used in the X Server needs to be a dynamically loaded X module. The one used by the 3D client driver is statically linked into the 3D client driver's shared library. Hmmm, thinking about this some more, I wonder if the staticly linked DRMLib will be a problem if we ever try to support direct rendering to multiple heads. If each head required a different driver, then the drm symbols would colide. Sorry, just thinking out loud... Assumptions: a) The DRM Lib in the X Server gets its inputs from the RM path which comes via the X Transport between it and the 3DDRP. b) In the 3DDRP (aplpication's user process) everything except XLib has either direct or indirect access to the DRM Lib in the 3DDRP. c) Now by looking at XLib in the 2D only Program and in the 3DIRP it is not concerned with the RM path / the DRM Lib in the X Server. Would it not be better (simpler / faster) to do resource management via the DRM Lib in the 3DDRP than via the DRM Lib in the X Server? Whether it would or whether it would not and why would be useful, I think it is a reasonable question even though it has assumptions. Liam it depends N2S: hw / sw accel. * (in)direct Rendering explane dif's. ___ 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] tuxkart, and bug reports..
On Wed, Jun 12, 2002 at 07:31:29 +0100, Keith Whitwell wrote: Yeah! Let's burn Rome! ;o) OK, maybe I'm getting carried away. But as I see it, there aren't many people in total on dri_devel+dri_users. The only people who can really answer dri_users questions are on dri_devel anyway. Why have two lists? I agree with Keith here (speaking as the list administrator too :) ) We also have dri-announce which doesn't get used at all. We always make announcements by posting to dri-users/dri-devel. So we might as well delete that one too. Alan. ___ 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] tuxkart, and bug reports..
I personally think we shouldn't do this, but I'll go for what the majority decides - after all it's what's the majority will do in the end that will really matter. So, speak up now, or forever remain quiet... I think if someone posts a good bug report, maybe even 1/2 a fix and is willing to play around and most important of all tests the fixes that are done and reports back, then it probably doesn't matter where they post or who/what they are. The rest deserve redhat and bugzilla ;o) -- Michael. ___ 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] tuxkart, and bug reports..
On Wednesday 12 June 2002 19:49, Keith Whitwell wrote: The dri-users list was founded on the idea that there might be a class of 'power users' out there who would altruistically help newbies get their setup working so that 'real developers' could concentrate on loftier ideas. That class of power users haven't really emerged, if anything it is the power users who are crying for help in the blackness of dri-users, as everyone else just sucks whatever comes with their distro. Again - I think the people on dri-users would be better off just posting to dri-devel. As it looks like we've got to monitor both lists, why bother having a second list? I know I give less attention to posts with [dri-users] than [dri-devel] -- perhaps I think that people posting there will never do any development, so I won't be repayed by spending my time on them. Please also look it from the other side : do the dri users want to get the dri devel mails ? That could just be a bit to much mail pouring into their mailboxes that doesn't help them anyway. If you want my opinion, I vote for users devel and damn close that bugtracking system. Look at what the KDE people use for bug tracking, now that's what i call neat (together with the nice KCrash backtracer). http://bugs.kde.org/ Peter Shut it down, let them post on dri-devel. Keith ___ 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] tuxkart, and bug reports..
Peter Soetens (Kaltan) wrote: On Wednesday 12 June 2002 19:49, Keith Whitwell wrote: The dri-users list was founded on the idea that there might be a class of 'power users' out there who would altruistically help newbies get their setup working so that 'real developers' could concentrate on loftier ideas. That class of power users haven't really emerged, if anything it is the power users who are crying for help in the blackness of dri-users, as everyone else just sucks whatever comes with their distro. Again - I think the people on dri-users would be better off just posting to dri-devel. As it looks like we've got to monitor both lists, why bother having a second list? I know I give less attention to posts with [dri-users] than [dri-devel] -- perhaps I think that people posting there will never do any development, so I won't be repayed by spending my time on them. Please also look it from the other side : do the dri users want to get the dri devel mails ? That could just be a bit to much mail pouring into their mailboxes that doesn't help them anyway. If you want my opinion, I vote for users devel Peter has a point, here. Besides, what's the difference between tracking 20 e-mails on one list and 5 e-mails on a second list; vs 25 e-mails on a common list? Perhaps I'm showing my lack of sophisticaed e-mail prowess :-) and damn close that bugtracking system. Look at what the KDE people use for bug tracking, now that's what i call neat (together with the nice KCrash backtracer). http://bugs.kde.org/ I'm certainly as guilty as anyone for letting the cruft build up in the SF bug tracker. However, from a TG commercial perspective, I will need to closely track all bugs specifically related for certain DRI projects. I can track those on a private internal database, or I can do it on an open DRI database. Either will work for me. However, I do think tracking on an open DRI database would be better for the DRI project; and I would prefer to use the slow SF bug database then take on the much larger task of setting up a new system. -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado ___ 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] tuxkart, and bug reports..
On Wed, Jun 12, 2002 at 02:28:45 -0600, Jens Owen wrote: Peter Soetens (Kaltan) wrote: On Wednesday 12 June 2002 19:49, Keith Whitwell wrote: The dri-users list was founded on the idea that there might be a class of 'power users' out there who would altruistically help newbies get their setup working so that 'real developers' could concentrate on loftier ideas. That class of power users haven't really emerged, if anything it is the power users who are crying for help in the blackness of dri-users, as everyone else just sucks whatever comes with their distro. Again - I think the people on dri-users would be better off just posting to dri-devel. As it looks like we've got to monitor both lists, why bother having a second list? I know I give less attention to posts with [dri-users] than [dri-devel] -- perhaps I think that people posting there will never do any development, so I won't be repayed by spending my time on them. Please also look it from the other side : do the dri users want to get the dri devel mails ? That could just be a bit to much mail pouring into their mailboxes that doesn't help them anyway. If you want my opinion, I vote for users devel Peter has a point, here. Besides, what's the difference between tracking 20 e-mails on one list and 5 e-mails on a second list; vs 25 e-mails on a common list? Perhaps I'm showing my lack of sophisticaed e-mail prowess :-) I'm wondering what dri-users actually serves at the moment. What proportion of the people there are actually compiling up the DRI trunk and actively testing it ? Or are using stock XFree86 4.2.0 and asking questions there instead ? I suspect that it may be better for those people not using the DRI trunk to post to the xpert list at XFree86 to answer questions like that. That way they get a broader audience. Most(?) of the dri developers are on xpert too. Yes ? I bet most dri developers get a ton of email already. I certainly do. :) And if people are really compiling the DRI trunk, I would appreciate any feedback - bad or good on dri-devel. and damn close that bugtracking system. Look at what the KDE people use for bug tracking, now that's what i call neat (together with the nice KCrash backtracer). http://bugs.kde.org/ I'm certainly as guilty as anyone for letting the cruft build up in the SF bug tracker. However, from a TG commercial perspective, I will need to closely track all bugs specifically related for certain DRI projects. I can track those on a private internal database, or I can do it on an open DRI database. Either will work for me. However, I do think tracking on an open DRI database would be better for the DRI project; and I would prefer to use the slow SF bug database then take on the much larger task of setting up a new system. We really need to clean up the stuff on SF now. Probably about 90% don't even apply now, or should at least be re-tested. Alan. ___ Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: tuxkart, and bug reports..
On Wednesday 12 June 2002 20:53, Alan Hourihane wrote: [-] We really need to clean up the stuff on SF now. Probably about 90% don't even apply now, or should at least be re-tested. Yes, let's start with that. There are even several bugs for which the sender asked for closing but never happend... Maybe we can change the maintenance so that the original poster can close it himself? -Dieter ___ 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] tcl branch merge
Keith Whitwell wrote: Keith Whitwell wrote: Although we still have a couple of bugs a lockup on the tcl branch, the situation is in general better than what's on the trunk I'd like to get that code merged now. This will also help get the 8500 branch started. OK. It's merged. I see that there are some differences in xc/xc/extras/Mesa/src vs. the latest 4.0.3 sources. I'll try to sync them up tomorrow, unless you beat me to it. -Brian ___ Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: tuxkart, and bug reports..
j == j r fonseca Jos writes: j In theory, dri-devel should be mainly for communication between all j developers and beta-testers. The dri-users should be for everybody else. j This is what I see in many other projects and it works quite well. Giving the stage of the (e.g. Radeon 8500) drivers I'd say every user using them is a beta tester ;-). i.e. at least for me radeon.o always locks up my box with glxgears ;-(. Bye, Adam. -- Adam Duck ([EMAIL PROTECTED]) Bockenheimer Landstr. 135 / Zi. 211 60325 Frankfurt/Main __ If it jams, force it. If it breaks, it needed replacing anyway. ___ 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] tuxkart, and bug reports..
For what it's worth, it runs great now here. I've actually finished a game or two without any lockups. Adam On Wed, 12 Jun 2002, Michael wrote: On Wed, Jun 12, 2002 at 12:57:37PM -0400, Adam K Kirchhoff wrote: Two quick questions :-) First, can anyone tell me if the issues with tuxkart and the Radeon driver from the TCL branch (well, now the trunk) have been fixed? Keith fixed a problem with line loops that was causing crashes. It now works for me (more importantly for the 3yo who actually wants to play ita) It still crashes for Keith (at least as of Monday). -- Michael. ___ 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: tuxkart, and bug reports..
Dieter Nützel wrote: On Wednesday 12 June 2002 20:53, Alan Hourihane wrote: [-] We really need to clean up the stuff on SF now. Probably about 90% don't even apply now, or should at least be re-tested. Yes, let's start with that. There are even several bugs for which the sender asked for closing but never happend... Maybe we can change the maintenance so that the original poster can close it himself? I think that only project developers/techs/admins can close bug reports. -Brian ___ 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] Status of AMD 760MP + Radeon lockups?
On Mon, 10 Jun 2002, Linus Torvalds wrote: If you have an AMD system and have seen problems with GART usage, and are willing to test out stuff, please give this a try. I'd love to hear actual user reports about whether this actually solves any problems. The DRI lockup on switching console back to X I am seeing still occurs with 2.4.19-pre10 plus the pageattr-B1-2.4.19-pre10 patch recently posted to LKML by Ben LaHaise. For the record, the other relevant details of my system are a Radeon VE QY video card, Tyan S2460 motherboard (AMD 760MP chipset) and RedHat XFree86-4.2.0-8. On a similar system, replacing the motherboard with an ASUS A7M266-D (AMD 760MPX chipset) eliminated the lockup. As both chipsets use the AMD 762 northbridge, I guess either the motherboards program the northbridge differently, or else there is some interaction with the two different southbridges (AMD 766 in 760MP, AMD 768 in 760MPX). Wayne ___ 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] tuxkart, and bug reports..
On 2002.06.12 21:53 Alan Hourihane wrote: On Wed, Jun 12, 2002 at 02:28:45 -0600, Jens Owen wrote: ... I'm certainly as guilty as anyone for letting the cruft build up in the SF bug tracker. However, from a TG commercial perspective, I will need to closely track all bugs specifically related for certain DRI projects. I can track those on a private internal database, or I can do it on an open DRI database. Either will work for me. However, I do think tracking on an open DRI database would be better for the DRI project; and I would prefer to use the slow SF bug database then take on the much larger task of setting up a new system. Jens, although I understand that TG needs to track bugs, this by itself isn't enough to guarantee that the SF bug database is adequate. Even if we do clean it as Alan suggests, unless everyone agrees to give it the proper use [and acts accordingly after] then it's just a matter of time to everything happens again, and everyone will loose: - users have 3 places to post bugs, and it's not clear which is ideal (it's not the first time I read on dri-devel I already posted this on dri-users but got no answer...) - developers have three places to monitor where at least of them [SF bug database] doesn't appeal to them, so it will be ignored most of the time. - TG doesn't have a real bug database as most of the bugs eventually get reported on dri-devel [where they are most likely answered], and most of those which are reported on SF probably aren't valid or close since no one really looks at them. What TG gets it's a endless list of problems reports which requires annual maintainance [in other words, removal...] I really hoped from this discussion that this wouldn't happen, i.e., making the same mistakes 2nd time... We really need to clean up the stuff on SF now. Probably about 90% don't even apply now, or should at least be re-tested. If the SF bug database goes on, then I may ask: Who here plans to plans to answer and follow the bug reports? I'd prefer that we _truly_ agree on a viable solution rather than just appearently agree on an assumed impossible solution... Well, just my 2c... José Fonseca ___ 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] tuxkart, and bug reports..
Keith Whitwell wrote: OK, maybe I'm getting carried away. But as I see it, there aren't many people in total on dri_devel+dri_users. The only people who can really answer dri_users questions are on dri_devel anyway. Why have two lists? There aren't a great number of dri_users questions anyway and a good percentage of them probably should be on dri_devel as it stands now (they're proper bugs, or whatever). So, I guess I still think the second list: - doesn't serve it's intended audience well - doesn't save us any time (except by making it easier to ignore users). But, I don't feel anywhere near as strongly about this as about the sourceforge bug tracker. I can live with either outcome. I started on dri-users. There was very little traffic. What traffic there was seemed to be questions that sometimes got answered. The FAQ was out of date, the web site was out of date, looking at the downloads for the project only served to confuse people... So, I lurked for a few months. After getting dri working on a few of my machines, and seeing that there was actual motion on the mach64 driver, I joined dri-devel to see what was happening. That helped a lot. I initally wanted to disagree with Keith that the lists should be merged, but it might solve the problem I had--that there is just too little information available to the dri-users and there is no indication that anything is happening. I was quite dissapoinited with dri-users for that. Since I sub'd to dri-devel, I see that there is a very active development community and three big projects in the works (radeon, radeon TL, and mach64). There's no hint of this in the dri-users world. Since I own a Radeon QD and a Mach64 (Rage LT Pro), I was delighted to see the work that is going on and have already run some beta testing on the mach64. I guess what I'd like to say is that there is reason to have dri-users and dri-devel seperate as they have different uses. dri-users is more for startup and newbie questions. dri-devel is for developers to converse. And, yes, there should be a crowd of 'power users' spanning the bridge, but that takes time to develop. I'm starting to feel comfortable enough with the DRI to be able to help out over there and I only expect that to increase. The re-write of the web pages should help, as well. The recent discussion on what the data/call flow charts should look like--if captured on the web site--would be an invaluable resource to get more 'power users' bootstrapped. The problem with this subject is the same as it's always been in graphics--there are those who know a bunch and get *real work* done and the rest who are within one step (above or below) clueless. There isn't much middle ground. It took the better part of a decade for linux-kernel to build up that middle ground of power users. I wouldn't expect it to happen over night for DRI. So, I'd recommend that things keep on like they have been. Keep the lists as they are. Update the web site. Distribute some point release betas of code (not just nightly tar balls or CVS--those are almost useless to the would be power user). Announce the code releases. Having an almost un- documented web page with nightly tarballs or anon CVS access is pretty user- hostile. Now that TL is merged, how about a point beta? Shake up the dri-users. Sounds like the Mach64 code hand grenade just got the pin put back in-- how about a point beta? Oh, and I have an nVidia Riva ZX that nVidia doesn't care to support. Anyone want it? Nice little 8M AGP card looking for a loving developer... ;) Cheers, David ___ 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] tuxkart, and bug reports..
There aren't a great number of dri_users questions anyway and a good=20 percentage of them probably should be on dri_devel as it stands now (they= 're=20 proper bugs, or whatever). So, I guess I still think the second list: - doesn't serve it's intended audience well - doesn't save us any time (except by making it easier to ignore users). But, I don't feel anywhere near as strongly about this as about the=20 sourceforge bug tracker. I can live with either outcome. One thing that you might want to explore is closing off dri-devel from the average user and trying to shift a majority of the traffic to dri-users and keep dri-devel strictly on the development side of dri instead of having it double as a help mailing list. Just my $.02. -- John Tobin [EMAIL PROTECTED]; AOL IM: ogre7929 http://ogre.rocky-road.net http://ogre.rocky-road.net/cdr.shtml ___ Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Radeon problems with rendering into front buffer.
Hi. I've recently compiled new code with tcl-branch merged. I've encountered problem when rendering into front buffer and having double-buffered visual. It seems that glDrawBuffer must be called ech time after radeonUpdatePageFlipping or the app starts rendering into back buffer. My guess is that we have to check which buffer we are rendering into not only what type of visual do we have in radeonUpdatePageFlipping radeon_lock.c: line 61. Unfrotunately at this point my knowledge is not enough to do properly it by myself but I'am learnig. Jacek -- Darmowe konta e-mail 30 MB, w idealnej domenie, czyli [EMAIL PROTECTED] i wszystko jasne! Zapraszamy! http://www.twoje.konto.pl ___ Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: tcl branch merge
Brian Paul wrote: Keith Whitwell wrote: Keith Whitwell wrote: Although we still have a couple of bugs a lockup on the tcl branch, the situation is in general better than what's on the trunk I'd like to get that code merged now. This will also help get the 8500 branch started. OK. It's merged. I see that there are some differences in xc/xc/extras/Mesa/src vs. the latest 4.0.3 sources. I'll try to sync them up tomorrow, unless you beat me to it. And the below trunk file should look like this, again: xc/xc/lib/GL/mesa/src/drv/Imakefile SUBDIRS = common DriDrivers _NOT_ SUBDIRS = common radeon Cheers, Dieter ___ 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 problems with rendering into front buffer.
Jacek Rosik wrote: Hi. I've recently compiled new code with tcl-branch merged. I've encountered problem when rendering into front buffer and having double-buffered visual. It seems that glDrawBuffer must be called ech time after radeonUpdatePageFlipping or the app starts rendering into back buffer. My guess is that we have to check which buffer we are rendering into not only what type of visual do we have in radeonUpdatePageFlipping radeon_lock.c: line 61. Unfrotunately at this point my knowledge is not enough to do properly it by myself but I'am learnig. Yes, you're right. Have a look at the other places where drawOffset is set - I think we get it right there you can copy the logic. Keith ___ 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: tcl branch merge
And the below trunk file should look like this, again: xc/xc/lib/GL/mesa/src/drv/Imakefile SUBDIRS = common DriDrivers _NOT_ SUBDIRS = common radeon Done. Thanks. Keith ___ 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: tuxkart, and bug reports..
Dieter Nützel wrote:
On Wednesday 12 June 2002 20:53, Alan Hourihane wrote:
[-]
We really need to clean up the stuff on SF now. Probably about 90%
don't even apply now, or should at least be re-tested.
Yes, let's start with that.
There are even several bugs for which the sender asked for closing but never
happend... Maybe we can change the maintenance so that the original poster
can close it himself?
-Dieter
I've posted and fixed bug #565927. I've posted patch but after this
discussion I posting it also to this list becouse this bug is still in
new code.
It's about problems with clearing in radeonClear. With to many clipping
rectangles driver entered infinite loop locking whole machine as X
server was waiting to obtain hardware lock.
I'am new to DRI as a developer and I'am still learning it's structure
but I wanted to know what else should I do to become a DRI member?
Jacek.
___
Sponsored by:
ThinkGeek at http://www.ThinkGeek.com/
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
--- xc/lib/GL/mesa/src/drv/radeon/radeon_ioctl.cWed Jun 12 19:03:59 2002
+++ ../build/dri/xc/lib/GL/mesa/src/drv/radeon/radeon_ioctl.c Wed Jun 12 20:01:42
+2002
@@ -856,14 +856,14 @@
clear.depth_mask = rmesa-state.stencil.clear;
clear.depth_boxes = depth_boxes;
- nr = rmesa-sarea-nbox;
+ n--;
b = rmesa-sarea-boxes;
- for ( i = 0 ; i nr ; i++ ) {
-depth_boxes[i].f[RADEON_CLEAR_X1] = (float)b[i].x1;
-depth_boxes[i].f[RADEON_CLEAR_Y1] = (float)b[i].y1;
-depth_boxes[i].f[RADEON_CLEAR_X2] = (float)b[i].x2;
-depth_boxes[i].f[RADEON_CLEAR_Y2] = (float)b[i].y2;
-depth_boxes[i].f[RADEON_CLEAR_DEPTH] =
+ for ( ; n = 0 ; n-- ) {
+depth_boxes[n].f[RADEON_CLEAR_X1] = (float)b[n].x1;
+depth_boxes[n].f[RADEON_CLEAR_Y1] = (float)b[n].y1;
+depth_boxes[n].f[RADEON_CLEAR_X2] = (float)b[n].x2;
+depth_boxes[n].f[RADEON_CLEAR_Y2] = (float)b[n].y2;
+depth_boxes[n].f[RADEON_CLEAR_DEPTH] =
(float)rmesa-state.depth.clear;
}
[Dri-devel] radeon 2 app crash
I've just noticed some combinations of 2 apps running at once causes hangs (well, I had glxgears minimised and had forgotten and ran q3) A wild stab in the dark. When we currently send a cmd buffer something like this :- app 1 packet 1 app2 packet 1 5 (LOAD_VBPNTR) 5 (LOAD_VBPNTR) ... state State -FLUSH HERE cmd packet full 6 cmd packet 2elts 6 (CLIP_PACKET3) FLUSH HERE elts state 5 packet 6 FLUSH here If we flush packet 1, what happens if another app sends a cmd packet to the card with a few 5 + state + 6 packet sequences? Don't we then send our elts with whatever the last LOAD_VBPTR command was (i.e possibly a different applications) instead of our own when we flush packet 2? Perhaps I'm missing something or completely off the wall, but adding a FlushCmdBuf to force each command buf to start with a 5 packet seems to eliminate the hang (but I'm wary that the frequent flushing may have fixed the real problem) -- Michael. ___ Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Default AGP mode
It would appear that AGP mode 1x is used by default always unless the AGPmode option is specified in the config file. (Correct me if I'm not completely correct with that). I'm wondering if the default can be changed to be the fastest sane mode supported by the hardware and/or configured by the BIOS. I'm unfamiliar with any discussions that may have previously occured or the rationales behind the existing defaults. If possible I'd like to change the defaults to be more sane to modern hardware. Any comments? -- 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
Re: [Dri-devel] Default AGP mode
On Wed, Jun 12, 2002 at 08:35:15PM -0400, Mike A. Harris wrote: It would appear that AGP mode 1x is used by default always unless the AGPmode option is specified in the config file. (Correct me if I'm not completely correct with that). I'm wondering if the default can be changed to be the fastest sane mode supported by the hardware and/or configured by the BIOS. Probably. The 2d side (unless it's a bug) doesn't have break statements in the place it sets the agp mode flags...I think the kernel then works from 4 down. Assuming that's not a bug you can probably default the user side to 4 and the kernel should check for capability as it seems to do that now. -- Michael. ___ 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] Default AGP mode
From: Mike A. Harris [EMAIL PROTECTED] Date: Wed, 12 Jun 2002 20:35:15 -0400 (EDT) It would appear that AGP mode 1x is used by default always unless the AGPmode option is specified in the config file. (Correct me if I'm not completely correct with that). I'm wondering if the default can be changed to be the fastest sane mode supported by the hardware and/or configured by the BIOS. In fact it's wrong when the user has selected a different mode from the BIOS setup especially on chips where we do not know how to fully program the hardware when switching modes correctly. I think the default should be whatever mode the chipset is in when AGP is started. ___ 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] Default AGP mode
On Wed, 12 Jun 2002, David S. Miller wrote: Date: Wed, 12 Jun 2002 18:08:37 -0700 (PDT) From: David S. Miller [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Content-Type: Text/Plain; charset=us-ascii Subject: Re: [Dri-devel] Default AGP mode From: Mike A. Harris [EMAIL PROTECTED] Date: Wed, 12 Jun 2002 20:35:15 -0400 (EDT) It would appear that AGP mode 1x is used by default always unless the AGPmode option is specified in the config file. (Correct me if I'm not completely correct with that). I'm wondering if the default can be changed to be the fastest sane mode supported by the hardware and/or configured by the BIOS. In fact it's wrong when the user has selected a different mode from the BIOS setup especially on chips where we do not know how to fully program the hardware when switching modes correctly. Indeed. I just wasnt aware of the specifics of how things are currently done, and wether or not it is being done both optimally and safely. Stability trumping performance of course. ;o) I think the default should be whatever mode the chipset is in when AGP is started. Agreed, that was my opinion as well. I just wasn't 100% sure how it is currently defaulting, and I figured I'd ask here prior to examining the source code. Having the BIOS default to say 2x, and having X default to 1x, or worse, having the BIOS default to 8x and X default to 1x or 2x is the situation that I'm curious to determine if we're avoiding, or if it is a chipset specific thing, etc. Basically, someone has asked for me to default AGPMode to 4 in our config file, which I thought was absolutely crazy. The claim is that AGP defaulted to 1x, but changing it to 4x sped things up dramatically. That is what lead me to believe that the default being used is not the BIOS setting. I'm going to explore the source code tonight, and see what if anything I might be able to poke around. Thanks for the feedback David. -- 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
Re: [Dri-devel] tuxkart, and bug reports..
--- José Fonseca [EMAIL PROTECTED] wrote: On 2002.06.12 18:49 Keith Whitwell wrote: ... I totally disagree here... That class of power users haven't really emerged, if anything it is the power users who are crying for help in the blackness of dri-users, as everyone else just sucks whatever comes with their distro. I had several problems with Debian and the TCL branch, whitch I worked ought. I noticed several times that users do answer to other users when they know the answer. It seems that most of that class of power users has migrated to dri-devel, by force of the circunstances, i.e., because it was there where all developers where... Agreed. __ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com ___ 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] tuxkart, and bug reports..
--- David Willmore [EMAIL PROTECTED] wrote: Keith Whitwell wrote: OK, maybe I'm getting carried away. But as I see it, there aren't many people in total on dri_devel+dri_users. The only people who can really answer dri_users questions are on dri_devel anyway. Why have two lists? There aren't a great number of dri_users questions anyway and a good percentage of them probably should be on dri_devel as it stands now (they're proper bugs, or whatever). So, I guess I still think the second list: - doesn't serve it's intended audience well - doesn't save us any time (except by making it easier to ignore users). But, I don't feel anywhere near as strongly about this as about the sourceforge bug tracker. I can live with either outcome. I guess what I'd like to say is that there is reason to have dri-users and dri-devel seperate as they have different uses. dri-users is more for startup and newbie questions. dri-devel is for developers to converse. And, yes, there should be a crowd of 'power users' spanning the bridge, but that takes time to develop. I'm starting to feel comfortable enough with the DRI to be able to help out over there and I only expect that to increase. The re-write of the web pages should help, as well. The recent discussion on what the data/call flow charts should look like--if captured on the web site--would be an invaluable resource to get more 'power users' bootstrapped. So, I'd recommend that things keep on like they have been. Keep the lists as they are. Update the web site. Distribute some point release betas of code (not just nightly tar balls or CVS--those are almost useless to the would be power user). Announce the code releases. Having an almost un- documented web page with nightly tarballs or anon CVS access is pretty user- hostile. Now that TL is merged, how about a point beta? Shake up the dri-users. Sounds like the Mach64 code hand grenade just got the pin put back in-- how about a point beta? Oh, and I have an nVidia Riva ZX that nVidia doesn't care to support. Anyone want it? Nice little 8M AGP card looking for a loving developer... ;) Cheers, David I'd like to see some point releases as it sits now I just take a weekly snapshot whenever I get the chance. It would be nice to know if there is some new feature just added that I should test, dri-devel gives me this. As for dri-users I like having them both. I however can't see having both dri-users and SFBT. I can start answering questions posted to dri-users, should I also keep an eye on the SFBT? __ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com ___ Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Strange behavior of the TCL branch
I have an ATI Radeon LE (which is pretty much the same card as the ATI Radeon DDR but only with 32megs of DDR ram not 64). Specifically: Linux misato 2.4.19-pre10 #1 Tue Jun 4 04:44:29 EDT 2002 i686 unknown using: XFree86 Version 4.2.0 (DRI trunk) / X Window System (protocol Version 11, revision 0, vendor release 6600) Release Date: 18 January 2002 checked out with: cvs -z3 -d :pserver:[EMAIL PROTECTED]:/cvsroot/dri co -rtcl-0-0-branch xc my pci list: 00:00.0 Host bridge: Intel Corp. 82815 815 Chipset Host Bridge and Memory Controller Hub (rev 04) 00:01.0 PCI bridge: Intel Corp.: Unknown device 1131 (rev 04) 00:1e.0 PCI bridge: Intel Corp. 82820 820 (Camino 2) Chipset PCI (rev 11) 00:1f.0 ISA bridge: Intel Corp. 82820 820 (Camino 2) Chipset ISA Bridge (ICH2) (rev 11) 00:1f.1 IDE interface: Intel Corp. 82820 820 (Camino 2) Chipset IDE U100 (rev 11) 00:1f.2 USB Controller: Intel Corp. 82820 820 (Camino 2) Chipset USB (Hub A) (rev 11) 00:1f.3 SMBus: Intel Corp. 82820 820 (Camino 2) Chipset SMBus (rev 11) 00:1f.4 USB Controller: Intel Corp. 82820 820 (Camino 2) Chipset USB (Hub B) (rev 11) 01:00.0 VGA compatible controller: ATI Technologies Inc Radeon QD 02:01.0 Multimedia audio controller: Ensoniq 5880 AudioPCI (rev 02) 02:02.0 Ethernet controller: Digital Equipment Corporation DECchip 21041 [Tulip Pass 3] (rev 21) 02:03.0 Ethernet controller: 3Com Corporation 3c900B-TPO [Etherlink XL TPO] (rev 04) 02:04.0 Multimedia video controller: Brooktree Corporation Bt878 (rev 02) 02:04.1 Multimedia controller: Brooktree Corporation Bt878 (rev 02) glxinfo: name of display: :0.0 radeonUpdatePageFlipping allow 0 current 0 display: :0 screen: 0 direct rendering: Yes server glx vendor string: SGI server glx version string: 1.2 server glx extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context client glx vendor string: SGI client glx version string: 1.2 client glx extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context GLX extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context OpenGL vendor string: Tungsten Graphics, Inc. OpenGL renderer string: Mesa DRI Radeon 20020309 AGP 4x x86/MMX/SSE TCL OpenGL version string: 1.2 Mesa 4.0.1 OpenGL extensions: GL_ARB_imaging, GL_ARB_multitexture, GL_ARB_texture_env_add, GL_ARB_transpose_matrix, GL_EXT_abgr, GL_EXT_bgra, GL_EXT_blend_color, GL_EXT_blend_logic_op, GL_EXT_blend_minmax, GL_EXT_blend_subtract, GL_EXT_clip_volume_hint, GL_EXT_convolution, GL_EXT_compiled_vertex_array, GL_EXT_histogram, GL_EXT_packed_pixels, GL_EXT_polygon_offset, GL_EXT_rescale_normal, GL_EXT_secondary_color, GL_EXT_texture3D, GL_EXT_texture_env_add, GL_EXT_texture_env_combine, GL_EXT_texture_env_dot3, GL_EXT_texture_filter_anisotropic, GL_EXT_texture_object, GL_EXT_texture_lod_bias, GL_EXT_vertex_array, GL_IBM_rasterpos_clip, GL_MESA_window_pos, GL_NV_texgen_reflection, GL_SGI_color_matrix, GL_SGI_color_table glu version: 1.2 Mesa 3.3 beta glu extensions: GL_EXT_abgr When I run any OpenGL game like say , RTCW or Q3 or even something with Wine (like JD2) I get rather poor performance. While playing any of the OGL games the frame rates aren't stable, approximtly once a second the game pauses for a small amount of time and then resumes... Even if I were to stay in the same place (i.e. not cause the game to texture swap by looking at a wall for example) the frame rate still drops to 0 every second (the game pauses the FPS counter drops and then counts back up). This happens in any opengl prog that i've tried, it looks like the driver is doing something at one second intervals that causes the software to wait. Now, the intesting part. I normally run overclocked (this bug report was produced for NON-OVERCLOCKED runs)... at 121MHZ FSB (with PCI divider of 3), my computer is very stable like that, I have multi-month uptimes with high load, however, the behaviour of this problems differs with bus speed. If I run the BUS at 100mhz (i.e. giving PCI normal 33mhz speed) this problem is a bit less noticebale because the pause appears to be shorter (however still present and still very noticeable). The higher the BUS speed becomes (for example 121mhz FSB with a PCI speed of 40mhz) the more noticeable the pauses are and more jerky the game feels. There were no such problems with the normal XF 4.2.0 release and an MGAG450... (at any bus speed) If any one is interested in more feedback or has questions of any kind I will be glad to help to the best of my ability (my email [EMAIL PROTECTED]). ___ 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] Default AGP mode
Mike A. Harris wrote: On Wed, 12 Jun 2002, David S. Miller wrote: Date: Wed, 12 Jun 2002 18:08:37 -0700 (PDT) From: David S. Miller [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Content-Type: Text/Plain; charset=us-ascii Subject: Re: [Dri-devel] Default AGP mode From: Mike A. Harris [EMAIL PROTECTED] Date: Wed, 12 Jun 2002 20:35:15 -0400 (EDT) It would appear that AGP mode 1x is used by default always unless the AGPmode option is specified in the config file. (Correct me if I'm not completely correct with that). I'm wondering if the default can be changed to be the fastest sane mode supported by the hardware and/or configured by the BIOS. In fact it's wrong when the user has selected a different mode from the BIOS setup especially on chips where we do not know how to fully program the hardware when switching modes correctly. Indeed. I just wasnt aware of the specifics of how things are currently done, and wether or not it is being done both optimally and safely. Stability trumping performance of course. ;o) I think the default should be whatever mode the chipset is in when AGP is started. Agreed, that was my opinion as well. I just wasn't 100% sure how it is currently defaulting, and I figured I'd ask here prior to examining the source code. Having the BIOS default to say 2x, and having X default to 1x, or worse, having the BIOS default to 8x and X default to 1x or 2x is the situation that I'm curious to determine if we're avoiding, or if it is a chipset specific thing, etc. Basically, someone has asked for me to default AGPMode to 4 in our config file, which I thought was absolutely crazy. The claim is that AGP defaulted to 1x, but changing it to 4x sped things up dramatically. That is what lead me to believe that the default being used is not the BIOS setting. I'm going to explore the source code tonight, and see what if anything I might be able to poke around. Thanks for the feedback David. Actually, its most safe to default to AGP mode 1x. If we aren't switching modes correctly there is a bug in that agp driver, and I'd like to know about it. Unforunately there is no real way to test if anything above AGP mode 1X works correctly. Defaulting to AGP mode 1X is the best option, since AGP mode 2X might cause the machine to lockup upon initiating a DMA request. Certain card/motherboard combinations just don't work above 1X. The default is there for a reason. Its the only real safe value. If we knew how to recover each card from a hang it might make sense to make up some sort of test during installation that discovers the best mode (I think this is how some windows drivers work). However we don't know how to do that for the most part, and it has to be accomplished for all hardware. Just add some options to the X config tools in RedHat that deal with it an allow the user to select and give them a HUGE warning that it might lock their machine above 1X. Thats probably the best solution if you want to allow them to configure this option. Anyway, that should sum up the previous discussions on the topic... -Jeff ___ Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Mach64 2D accel fixed!
Well, I had a Eureka! moment and figured out the problem with 2D accel, which was also the cause of the signal 11 on server shutdown. Hidden in atiaccel.c there is a second initialization of the framebuffer manager that was causing XAA to use the entire offscreen area (including our back, depth and texture areas) for the pixmap cache and offscreen pixmaps. What confused me was there was a _third_ intialization in atiscreen.c if direct rendering is disabled. I discovered that Gareth had added that and probably missed the one in atiaccel.c. So I removed the third init and bypassed the one in atiaccel.c for the direct rendering path. Between that and restoring the registers used by 3D driver in the XAA sync to the what the Xserver expected, I got 2D accel working. VT and mode switches also work now without locking up. I've also implemented the functions to init and move the back and depth buffers (with the exception of depth moves), based on the Rage128 and Radeon versions respectively. This makes moving windows much smoother. We've still got some problems with the scissors not being updated properly, which can be seen when moving windows. I've also had lockups with the texenv Mesa demo in single-buffered mode, which could be because of the scissors or the fact that we don't do cliprects for vertex buffers yet. I'm not sure what the cause is yet. OK, now for the bad news: the driver currently allocates only 128 scanlines for the XAA pixmap cache and offscreen pixmaps. This is what the calculations for the size of the local texture area have been based on. To get good 2D performance, we should probably allocate a full viewport's worth of offscreen mem for XAA. This will put an even bigger crunch on cards with less than 8MB of framebuffer mem. I think we'll need to figure out a good tradeoff here, and then include a config option so people can decide if 2D or 3D is more important to them. Dynamic allocation of back and depth buffers would help here and would allow using higher resolutions on cards with low mem. For people using Jose's binary packages from the DRI website: this should appear in the next build (will be named mach64-20020614..., I think), if you want to try it out. -- Leif Delgass http://www.retinalburn.net ___ 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] Default AGP mode
From: Jeff Hartmann [EMAIL PROTECTED] Date: Wed, 12 Jun 2002 21:57:31 -0500 Actually, its most safe to default to AGP mode 1x. If we aren't switching modes correctly there is a bug in that agp driver, and I'd like to know about it. Try to enable 4X in BIOS of SiS Athlon chipset, startup X in default mode, SPLAT. This is a widely known problem and you aren't going to get all of the chipsets right in particular the AMD76x ones. I'd suggest rethinking the use 1X by default logic, it's wrong in half of the cases. Unforunately there is no real way to test if anything above AGP mode 1X works correctly. Defaulting to AGP mode 1X is the best option, since AGP mode 2X might cause the machine to lockup upon initiating a DMA request. Certain card/motherboard combinations just don't work above 1X. I totally disagree, you're locking up now on half the chipsets if the user enables anything other than 1X mode in his BIOS. The reason the machine locks up on 1X mode is for the same damn reasons, the driver isn't programming the chip correctly or we lack the workaround which in a manner of speaking is the same problem. ___ 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] Default AGP mode
From: Mike A. Harris [EMAIL PROTECTED] Date: Wed, 12 Jun 2002 21:39:23 -0400 (EDT) Basically, someone has asked for me to default AGPMode to 4 in our config file, which I thought was absolutely crazy. The claim is that AGP defaulted to 1x, but changing it to 4x sped things up dramatically. That is what lead me to believe that the default being used is not the BIOS setting. That's almost as stupid as the current situation which defaults to 1X AGP. Another known failure case (when user sets BIOS to 4X and X tries to use it's default of 1X) is ALI M1647 chipsets. That also hangs. All of this points to using the BIOS supplied default as being the logical way to go. Until we can be confident that every single AGP chipset is %100 done and has %100 of the workarounds, I'd highly suggest against trying to switch AGP modes by default. To my knowledge only the ServerWorks AGP bits are a) written by the vendor b) have all the necessary errata workarounds. ___ 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
