Re: [Dri-devel] Mach64 2D accel fixed!
Hello! > That's great news, Leif! I used to test the Mach64-branch on my Sony Vaio which has a 8 MB ATI Rage Mobility. The mach64-0-0-3 branch worked fine for me and I was really happy because I got a frame rate of about 25-30 in UT and Q3. I had a lot of work to do for my diploma thesis lately, so I did not test the mach64-0-0-4 branch. But waht I read on the list lately sounds promising. Is the mach64-0-0-4 branch in a useable state now so that is worthwhile for a pure user to test it? I think I will go and download the branch tomorrow and will compare the results (glxgears, UT and Q3) to the mach64-0-0-3 branch. I really hope, 2D and 3D work together soon and I can switch the VTs (it is so hard to remember that you can't without crashing the computer:-)) Thanks to all developers that make the dream of 3D on the "old" Mach 64 come true! Greetings, Michael ___ 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] Re: tuxkart, and bug reports..
>
>
>
> --- xc/lib/GL/mesa/src/drv/radeon/radeon_ioctl.c Wed 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;
>}
>
>
Jacek,
Can you explain what this change actually does? You've changed the way the
loop condition is tested and the order of the loop, but I don't see any change
to the actual logic of the loop... Maybe I'm blind, but I don't understand
how this fixes your problem.
Keith
___
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
[Dri-devel] Texcache sharin', page flippin' sonuvagun
Keith Whitwell wrote: > Leif Delgass wrote: > >> CVSROOT:/cvsroot/dri >> Module name:xc >> Repository:xc/xc/programs/Xserver/hw/xfree86/drivers/ati/ >> Changes by:ldelgass@usw-pr-cvs1.02/06/12 20:48:11 >> >> Log message: >> Fixed and enbled 2D acceleration. Also ATIDRIInitBuffers and >> ATIDRIMoveBuffers >> are now implemented with XAA accel functions. We still have some >> problems >> with the scissors being updated (Mesa driver problem?) which can be >> seen when >> moving windows. We're only allocating 128 scanlines for pixmap >> cache and >> offscreen pixmaps for XAA. We should probably allocate a whole >> viewport's >> worth, but this will leave very little if any local texture memory >> for some >> cards (e.g. 4MB cards). We might need a config option there. > > > Have a look at the tdfx driver -- it dynamically allocates/deallocates > 2d pixcache according to whether there are any 3d clients -- so you get > decent 2d performance in the non-3d case. > > It's done in the 2d driver, search for "Transition" and "2D" or "3D". > > Keith Also have a look at the same functions in the radeon driver to set up a very easy if not-quite-perfect page-flipping mode. This is probably going to be a big boost for performance on slower cards... Keith ___ 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] Mach64 2D accel fixed!
On 2002.06.13 08:05 Michael Thaler wrote: > ... > > I had a lot of work to do for my diploma thesis lately, so I did not > test the mach64-0-0-4 branch. But waht I read on the list lately > sounds promising. Is the mach64-0-0-4 branch in a useable state now so > that is worthwhile for a pure user to test it? It's usable, and has also other goodies such as an improved DMA. This doesn't mean that is assured to be problem free, but if there are we are here for them, and want to hear about them. > .. José Fonseca ___ 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: Thu, 13 Jun 2002 02:58:53 -0400 (EDT) Ben LaHaise suggested tonigth to me on IRC that perhaps we could read the AGP mode from the BIOS and set that by default, and also keep blacklist/whitelists in the drivers/whatever to deal with side cases or known bad combinations. No need to read from the BIOS, just read the AGP registers. ___ 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
On Thu, 13 Jun 2002, David S. Miller wrote: >Date: Thu, 13 Jun 2002 00:53:16 -0700 (PDT) >From: David S. Miller <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Cc: [EMAIL PROTECTED], [EMAIL PROTECTED] >Content-Type: Text/Plain; charset=us-ascii >Subject: Re: [Dri-devel] Default AGP mode > > From: "Mike A. Harris" <[EMAIL PROTECTED]> > Date: Thu, 13 Jun 2002 02:58:53 -0400 (EDT) > > Ben LaHaise suggested tonigth to me on IRC that perhaps we could > read the AGP mode from the BIOS and set that by default, and also > keep blacklist/whitelists in the drivers/whatever to deal with > side cases or known bad combinations. > >No need to read from the BIOS, just read the AGP registers. Oops, bad wording on my part.. I meant "Read the BIOS configured AGP mode". I'll have a look at this tomorrow for sure and see if I can figure it out. Thanks again, TTYL -- 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 ___ 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] Strange behavior of the TCL branch
> "Slava" == Slava Polyakov <[EMAIL PROTECTED]> writes: Slava> I have an ATI Radeon LE (which is pretty much the same Slava> card as the ATI Radeon DDR but only with 32megs of DDR Slava> ram not 64). Slava> Specifically: Slava> Linux misato 2.4.19-pre10 #1 Tue Jun 4 04:44:29 EDT Slava> 2002 i686 unknown Slava> While playing any of the OGL games the frame rates Slava> aren't stable, approximtly once a second the game Slava> pauses for a small amount of time and then resumes... Slava> Even if I were to stay in the same place (i.e. not Slava> cause the game to texture swap by looking at a wall for Slava> example) the frame rate still drops to 0 every second Slava> (the game pauses the FPS counter drops and then counts Slava> back up). I don't know, but could something else be interferring here? I had similar Problems - i.e. the frame counter dropped (but not to 0) and went up again every second or so ... This was due to gkrellm. Shutting it down before playing q3/q2 helped. Do you have anything that's polling every second or so? Bye, Adam. -- Adam Duck ([EMAIL PROTECTED]) Bockenheimer Landstr. 135 / Zi. 211 60325 Frankfurt/Main __ I don't have a solution but I admire the 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] Re: [Dri-patches] [ dri-Patches-567160 ] Radeon lockups with to many cliprects.
Keith Whitwell wrote: > [EMAIL PROTECTED] wrote: > >> Patches item #567160, was opened at 2002-06-11 02:58 >> You can respond by visiting: >> http://sourceforge.net/tracker/?func=detail&atid=300387&aid=567160&group_id=387 >> >> >> Category: None >> Group: None >> Status: Open >> Resolution: None >> Priority: 5 >> Submitted By: Jacek Rosik (jrosik) >> Assigned to: Nobody/Anonymous (nobody) >> Summary: Radeon lockups with to many cliprects. >> >> Initial Comment: >> This patch fixes bug '[565927] ATI Radeon freezes system'. >> >> In function radeonClear when number of clipping >> rectandles exceeds RANEON_NR_SAREA_CLIPRECTS the driver >> enteres infininite loop having hardware lock and hangs >> XServer which waits for this lock (I think so ;-)). >> >> File to be patched >> 'xc/lib/GL/mesa/src/drv/radeon/radeon_ioctl.c'. > > > Can you check this is correct since the merge of the TCL branch, and > post the patch to the list instead of the patch-manager? (which should > also die, IMO). > > Keith I've alredy posted new patch to dri-devel. If sending patches to dri-devel is preffered method then you should update FAQ:How do Isubmit a patch? So new developers wont send it to patch-manager. Jacek > ___ > > 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 > -- Darmowe konta e-mail 30 MB, w idealnej domenie, czyli [EMAIL PROTECTED] i wszystko jasne! Zapraszamy! http://www.twoje.konto.pl ___ 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] Re: tuxkart, and bug reports..
Keith Whitwell wrote:
>
>>
>>
>>
>> --- 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.cWed
>> 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;
>>}
>>
>>
>
> Jacek,
>
> Can you explain what this change actually does? You've changed the way
> the loop condition is tested and the order of the loop, but I don't see
> any change to the actual logic of the loop... Maybe I'm blind, but I
> don't understand how this fixes your problem.
>
> Keith
>
Sorry.
The problem was not in the logic of operation but in in use of variable
'i' in this loop. After this loop it's value was never greater than
RADEON_NR_SAREA_CLIPRECTS and this variable is used in other loop (the
one containing 'smaller' one). It's value after the loop should be total
number of cliprects processed and send to hardware (correct me if I'am
wrong) not only in this pass. That's why we had this lockup. So I've
just used n wchich is not used after this loop. In my opinion each loop
should have it's own variable for iteration so we can avoid such
problems in future when for example someone changes some part of this
quite long loop not examining is as whole. In this case everything
worked well at firs sight.
Jacek
Sorry if my english isn't perfect but I'am not native english speaker
(writer ;-)).
--
Darmowe konta e-mail 30 MB, w idealnej domenie,
czyli [EMAIL PROTECTED] i wszystko jasne!
Zapraszamy! http://www.twoje.konto.pl
___
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] Re: tuxkart, and bug reports..
> Sorry. > > The problem was not in the logic of operation but in in use of variable > 'i' in this loop. After this loop it's value was never greater than > RADEON_NR_SAREA_CLIPRECTS and this variable is used in other loop (the > one containing 'smaller' one). It's value after the loop should be total > number of cliprects processed and send to hardware (correct me if I'am > wrong) not only in this pass. That's why we had this lockup. So I've > just used n wchich is not used after this loop. In my opinion each loop > should have it's own variable for iteration so we can avoid such > problems in future when for example someone changes some part of this > quite long loop not examining is as whole. In this case everything > worked well at firs sight. > > Jacek > > Sorry if my english isn't perfect but I'am not native english speaker > (writer ;-)). OK, thanks for the explanation. It certainly needs to be cleared up... I'll commit your patch. Keith ___ 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] Re: [Dri-patches] [ dri-Patches-567160 ] Radeon lockups with to many cliprects.
>> >> Can you check this is correct since the merge of the TCL branch, and >> post the patch to the list instead of the patch-manager? (which >> should also die, IMO). >> >> Keith > > > I've alredy posted new patch to dri-devel. If sending patches to > dri-devel is preffered method then you should update FAQ:How do Isubmit > a patch? So > new developers wont send it to patch-manager. We're in discussions about what needs to change. The bug database is one thing that's broken, and your patch made me realize that I'd really prefer patches to be posted directly to dri-devel. In general most of the sourceforge tools are painful & slow things down rather than actually helping. Keith ___ 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
David S. Miller wrote: >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. Hrm, interesting. > > 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. > Actually I wrote that code for them, but for that one I did have access to their engineers. :) The main problem is that I don't see how this is going to solve any problem. It might cure some of the problems, but it also causes some. For instance I know there were some early ALi chipsets that would completely hang the machine if a Matrox G400 was in any other mode than 1X. If you search the archives of Utah-GLX and early DRI you will probably come up with many other examples of such combinations. Perhaps you might try defaulting to the BIOS default mode, but I personally think it will cause more problems then it will fix. -Jeff ___ 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] Re: tuxkart, and bug reports..
I thought I would add my vote to the whole debate about what to do with the mailing lists and SFBT. I would like both lists to continue and for their proper uses to be enforced. I am not a developer or even a power user. I just like knowing what is going on with the development. Having a clear definition of what is appropriate to the different lists makes it a lot easier for me to read only the mail I want and not have to sort my way through large amounts of junk that I have no intrest in and can't help anyway. As for the SFBT I think it should be trashed if it isn't going to be used properly. I went looking for a easy bug to try and fix a while back and every bug I looked at didn't even exist. I do think that if a better solution could be worked out a bug database would be a great resource. It is kind of hard to sort through all the dri-devel list archive to try and find a bug that hasen't been fixed. Just my 2 cents. Steven ___ 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
[Dri-devel] Re: tuxkart, and bug reports..
On Wed, Jun 12, 2002 at 11:13:40PM +0200, 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? What would be great, is if someone assigned the bugs to relevant developers. Once someone is assigned to the bug report, they get emails whenever it's updated. But that someone needs to know who to charge with that bug report. Someone who would standup to maintain it would be GREAT! Alan. ___ 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] Re: tuxkart, and bug reports..
Steven Paul Lilly wrote: > I thought I would add my vote to the whole debate about what to do with the > mailing lists and SFBT. I would like both lists to continue and for their > proper uses to be enforced. I am not a developer or even a power user. I > just like knowing what is going on with the development. Having a clear > definition of what is appropriate to the different lists makes it a lot > easier for me to read only the mail I want and not have to sort my way > through large amounts of junk that I have no intrest in and can't help > anyway. As for the SFBT I think it should be trashed if it isn't going to be > used properly. I went looking for a easy bug to try and fix a while back and > every bug I looked at didn't even exist. I do think that if a better > solution could be worked out a bug database would be a great resource. It is > kind of hard to sort through all the dri-devel list archive to try and find > a bug that hasen't been fixed. Just my 2 cents. Here's one: On the radeon, the first time a 3d window is created, there is some screen corruption. It's probably the 2d driver getting something wrong. Keith ___ 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] Re: tuxkart, and bug reports..
Alan Hourihane wrote: > On Wed, Jun 12, 2002 at 11:13:40PM +0200, 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? >> > > What would be great, is if someone assigned the bugs to relevant > developers. Once someone is assigned to the bug report, they get > emails whenever it's updated. But that someone needs to know who > to charge with that bug report. > > Someone who would standup to maintain it would be GREAT! But even so it makes fixing bugs *slower* -- there's extra accounting work to do. I never use the sf website except to add new developers CVS access... I really think the mailing list is the best place for bug discussions. It gives new developers a chance to dive in, for instance. Keith ___ 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] Re: tuxkart, and bug reports..
On Thu, Jun 13, 2002 at 04:03:05PM +0100, Keith Whitwell wrote: > Alan Hourihane wrote: > >On Wed, Jun 12, 2002 at 11:13:40PM +0200, 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? > >> > > > >What would be great, is if someone assigned the bugs to relevant > >developers. Once someone is assigned to the bug report, they get > >emails whenever it's updated. But that someone needs to know who > >to charge with that bug report. > > > >Someone who would standup to maintain it would be GREAT! > > But even so it makes fixing bugs *slower* -- there's extra accounting work > to do. I never use the sf website except to add new developers CVS > access... > > I really think the mailing list is the best place for bug discussions. It > gives new developers a chance to dive in, for instance. Understood, but there's a lot of users out there that don't want to receive emails from dri-devel. They just want to submit a bug, walk away, then get some response back to say it's fixed, or someone's working on it, or it won't be fixed etc. But with the SF bug tracking system we are currently sending bug reports, patches etc to the dri-patches mailing list. Maybe we should re-route them to dri-devel to get more feedback. The problem we're facing is that there's no formal process to assigning the bug report, so no-one else knows whether someone could be working on it or not, thus duplicating effort. Development is ideally what we all want to be doing, but there's a few admin type tasks we really do have to bear - and that's the uphill struggle. Alan. ___ 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] Re: tuxkart, and bug reports..
On 2002.06.13 15:43 Alan Hourihane wrote: > ... > > What would be great, is if someone assigned the bugs to relevant > developers. Once someone is assigned to the bug report, they get > emails whenever it's updated. But that someone needs to know who > to charge with that bug report. > > Someone who would standup to maintain it would be GREAT! > > Alan. That person's time would be better spent by setting up a _real_ bug tracking system, where this would be done automatically, such as bugzilla or the debian one. I know that usually the saying is the other way around but... "we shouldn't have a person doing a machine's job"! José Fonseca ___ 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] Strange behavior of the TCL branch
On June 13, 2002 07:06 am, Adam Duck wrote: > > "Slava" == Slava Polyakov <[EMAIL PROTECTED]> writes: > > Slava> I have an ATI Radeon LE (which is pretty much the same > Slava> card as the ATI Radeon DDR but only with 32megs of DDR > Slava> ram not 64). > > Slava> Specifically: > Slava> Linux misato 2.4.19-pre10 #1 Tue Jun 4 04:44:29 EDT > Slava> 2002 i686 unknown > > > Slava> While playing any of the OGL games the frame rates > Slava> aren't stable, approximtly once a second the game > Slava> pauses for a small amount of time and then resumes... > Slava> Even if I were to stay in the same place (i.e. not > Slava> cause the game to texture swap by looking at a wall for > Slava> example) the frame rate still drops to 0 every second > Slava> (the game pauses the FPS counter drops and then counts > Slava> back up). > > I don't know, but could something else be interferring here? I had > similar Problems - i.e. the frame counter dropped (but not to 0) and > went up again every second or so ... This was due to gkrellm. Shutting > it down before playing q3/q2 helped. > Do you have anything that's polling every second or so? Nope In addition this problem wasn't present with the G450. ___ 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] Re: tuxkart, and bug reports..
On Thu, Jun 13, 2002 at 04:20:47PM +0100, José Fonseca wrote: > On 2002.06.13 15:43 Alan Hourihane wrote: > >... > > > >What would be great, is if someone assigned the bugs to relevant > >developers. Once someone is assigned to the bug report, they get > >emails whenever it's updated. But that someone needs to know who > >to charge with that bug report. > > > >Someone who would standup to maintain it would be GREAT! > > > >Alan. > > That person's time would be better spent by setting up a _real_ bug > tracking system, where this would be done automatically, such as bugzilla > or the debian one. > > I know that usually the saying is the other way around but... "we > shouldn't have a person doing a machine's job"! What I'm afraid might happen with setting up something like bugzilla, is the much more severe maintenance of it. If that person where to walk away from the project, we're much more stuck that where we are now with SF. O.k. I admit that the SF system is primitive, but it works without too much maintenance. It's just that we (as developers) aren't using it at all. And that's down to us. Alan. ___ 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] Re: tuxkart, and bug reports..
On Thursday 13 June 2002 17:17, Alan Hourihane wrote: > On Thu, Jun 13, 2002 at 04:03:05PM +0100, Keith Whitwell wrote: > > Alan Hourihane wrote: > > >On Wed, Jun 12, 2002 at 11:13:40PM +0200, 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? > > > > > >What would be great, is if someone assigned the bugs to relevant > > >developers. Once someone is assigned to the bug report, they get > > >emails whenever it's updated. But that someone needs to know who > > >to charge with that bug report. > > > > > >Someone who would standup to maintain it would be GREAT! > > > > But even so it makes fixing bugs *slower* -- there's extra accounting > > work to do. I never use the sf website except to add new developers CVS > > access... > > > > I really think the mailing list is the best place for bug discussions. > > It gives new developers a chance to dive in, for instance. > > Understood, but there's a lot of users out there that don't want > to receive emails from dri-devel. They just want to submit a bug, > walk away, then get some response back to say it's fixed, or someone's > working on it, or it won't be fixed etc. > > But with the SF bug tracking system we are currently sending bug > reports, patches etc to the dri-patches mailing list. Maybe we should > re-route them to dri-devel to get more feedback. > > The problem we're facing is that there's no formal process to assigning > the bug report, so no-one else knows whether someone could be working > on it or not, thus duplicating effort. > > Development is ideally what we all want to be doing, but there's a > few admin type tasks we really do have to bear - and that's the uphill > struggle. So as I'm currently not having developers CVS access I'll offer to help, here. But be patient with me if I sometimes assign the "wrong" developer to the "right" bug...;-) Due to the fact that I haven't read dri-patches for some time I'm not sure if all bug reports have reached the mailing list. Is it working? -Dieter BTW I'm not loving SF bug tracking, too. http://bugs.kde.org/wizard/index.php is much more advanced. ___ 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] Re: tuxkart, and bug reports..
On 2002.06.13 16:24 Alan Hourihane wrote: > ... > > What I'm afraid might happen with setting up something like bugzilla, > is the much more severe maintenance of it. If that person where to > walk away from the project, we're much more stuck that where we are > now with SF. O.k. I admit that the SF system is primitive, but it > works without too much maintenance. It's just that we (as developers) > aren't using it at all. And that's down to us. > I really don't see in what way, once setup, a bugzilla database would require more maintainance than the SF system. It's quite clear what the "low maintainance" of SF systems leads to..! And I think we are less dependent of anyone if we have an automatic system than otherwise. A system such as bugzilla can address everyone's needs (including Keith's and Jens'). Taking for example what is done in Gentoo linux: there is a default bug owner which is actually a mailing list. So every bug report and comments are received by every developer list, until someone reclaims ownership and removes the default owner. Basically is just like another mailing list, with the difference that the bugs get into a database. While you see bugzilla and debian bt system being succesfully used in big projects, I don't know of any project making real use of the SF bt system. Another thing that is very nice with bugzilla is that it can remember us, so you don't need to always login(!)... IMHO, if someone is serious in respect with a bug tracking system it should setup one that suits the DRI project need. And that work could be even used to bootstrap a XFree86 bugtracking system. Put a poor soul in charge with the SF system is just digging deeper... José Fonseca ___ 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] Re: tuxkart, and bug reports..
On Thu, 13 Jun 2002, Keith Whitwell wrote: > Here's one: > > On the radeon, the first time a 3d window is created, there is some screen > corruption. It's probably the 2d driver getting something wrong. > > Keith What sort of corruption? I'm curious because we have a similar problem with mach64, where the first 3d window started contains old back buffer images and clears don't seem to work, although some drawing does happen over the corrupted background. Moving the window fixes the problem. It doesn't happen with gears, but most other apps seem to be affected. -- Leif Delgass http://www.retinalburn.net ___ 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] Re: tuxkart, and bug reports..
Leif Delgass wrote: > On Thu, 13 Jun 2002, Keith Whitwell wrote: > > >>Here's one: >> >>On the radeon, the first time a 3d window is created, there is some screen >>corruption. It's probably the 2d driver getting something wrong. >> >>Keith >> > > What sort of corruption? I'm curious because we have a similar problem > with mach64, where the first 3d window started contains old back buffer > images and clears don't seem to work, although some drawing does happen > over the corrupted background. Moving the window fixes the problem. It > doesn't happen with gears, but most other apps seem to be affected. > > It looks like the pitch or some other thing isn't set correctly when doing the initial clear of the buffers. The clear is done via the clear ioctl, IIRC. I'm not really sure why the 2d driver needs to do those clears -- couldn't the 3d client do it when the context is first bound to a window? Keith ___ 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] Re: tuxkart, and bug reports..
On Thu, Jun 13, 2002 at 04:46:44PM +0100, Keith Whitwell wrote: > It's not that I'm being lazy when I say I don't want to use it. > > First of all, if someone has a bug they want me to fix, they should stick > around long enough to have an email conversation about it. I'm doing free > work for them, if I decide/am able to fix the bug, after all. > > The bug tracker gets in the way of any communication between me & the guy > with the bug. It adds useless work in terms of logging into sf, fighting > with their dumb web frontend, and whatever, every time I want to talk to > the other person. > > Then, worst of all, once I fix the bug I have to go in and tell the damn > thing that it's fixed. Why bother? The other guy presumably already > knows, having been involved throughout... Interactivity is one of the major problems. The hassle of logging into SF and talking with someone via that mechanism is agreeably terrible. I'm not doubting you on that at all. But you can't force the bug reporter to be on dri-devel. In this case I see the SF bug system as a mechanism for first call. Then hopefully - they leave their email address (that doesn't always happen), and you can begin the interactivity session. Once fixed, they already know it's fixed, so just 5 minutes to close the bug. That way it stops someone else picking it up and trying to work on something that's already been fixed. We certainly don't have to use it for logging every single thing we do on rectifying the bug. It's just a means of identifying the person resposible for fixing it, so others can poke at the developer too. Does anyone know whether we can enforce someone to leave their email address on the SF bug database ? Alan. ___ 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] Re: tuxkart, and bug reports..
Alan Hourihane wrote: > On Thu, Jun 13, 2002 at 04:46:44PM +0100, Keith Whitwell wrote: > >>It's not that I'm being lazy when I say I don't want to use it. >> >>First of all, if someone has a bug they want me to fix, they should stick >>around long enough to have an email conversation about it. I'm doing free >>work for them, if I decide/am able to fix the bug, after all. >> >>The bug tracker gets in the way of any communication between me & the guy >>with the bug. It adds useless work in terms of logging into sf, fighting >>with their dumb web frontend, and whatever, every time I want to talk to >>the other person. >> >>Then, worst of all, once I fix the bug I have to go in and tell the damn >>thing that it's fixed. Why bother? The other guy presumably already >>knows, having been involved throughout... >> > > Interactivity is one of the major problems. The hassle of logging > into SF and talking with someone via that mechanism is agreeably > terrible. I'm not doubting you on that at all. > > But you can't force the bug reporter to be on dri-devel. They can mail to it without subscribing. Keith ___ 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] Re: tuxkart, and bug reports..
On Thu, Jun 13, 2002 at 05:05:05PM +0100, Keith Whitwell wrote: > Alan Hourihane wrote: > >On Thu, Jun 13, 2002 at 04:46:44PM +0100, Keith Whitwell wrote: > > > >>It's not that I'm being lazy when I say I don't want to use it. > >> > >>First of all, if someone has a bug they want me to fix, they should stick > >>around long enough to have an email conversation about it. I'm doing > >>free work for them, if I decide/am able to fix the bug, after all. > >> > >>The bug tracker gets in the way of any communication between me & the guy > >>with the bug. It adds useless work in terms of logging into sf, fighting > >>with their dumb web frontend, and whatever, every time I want to talk to > >>the other person. > >> > >>Then, worst of all, once I fix the bug I have to go in and tell the damn > >>thing that it's fixed. Why bother? The other guy presumably already > >>knows, having been involved throughout... > >> > > > >Interactivity is one of the major problems. The hassle of logging > >into SF and talking with someone via that mechanism is agreeably > >terrible. I'm not doubting you on that at all. > > > >But you can't force the bug reporter to be on dri-devel. > > They can mail to it without subscribing. True. The other alternative is to completely close the bug-tracking system and don't allow it. Forcing people to email. It's currently what we do for XFree86 too anyway (no bug tracker) :) Alan. ___ 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] Re: tuxkart, and bug reports..
On Thu, Jun 13, 2002 at 04:49:57PM +0100, José Fonseca wrote: > On 2002.06.13 16:24 Alan Hourihane wrote: > >... > > > >What I'm afraid might happen with setting up something like bugzilla, > >is the much more severe maintenance of it. If that person where to > >walk away from the project, we're much more stuck that where we are > >now with SF. O.k. I admit that the SF system is primitive, but it > >works without too much maintenance. It's just that we (as developers) > >aren't using it at all. And that's down to us. > > > > I really don't see in what way, once setup, a bugzilla database would > require more maintainance than the SF system. It's quite clear what the > "low maintainance" of SF systems leads to..! And I think we are less > dependent of anyone if we have an automatic system than otherwise. > > A system such as bugzilla can address everyone's needs (including Keith's > and Jens'). Taking for example what is done in Gentoo linux: there is a > default bug owner which is actually a mailing list. So every bug report > and comments are received by every developer list, until someone reclaims > ownership and removes the default owner. Basically is just like another > mailing list, with the difference that the bugs get into a database. > > While you see bugzilla and debian bt system being succesfully used in big > projects, I don't know of any project making real use of the SF bt system. > Another thing that is very nice with bugzilla is that it can remember us, > so you don't need to always login(!)... > > IMHO, if someone is serious in respect with a bug tracking system it > should setup one that suits the DRI project need. And that work could be > even used to bootstrap a XFree86 bugtracking system. Put a poor soul in > charge with the SF system is just digging deeper... I don't think so. The SF system is overloaded - for the only reason is that the developers aren't even looking at them to close them. If someone where to go through the SF system and clean it all up, I think there will actually be very few bugs indeed. And we don't need to spend time on the bugzilla setup. If Dieter is volunteering to go through it - then power to him... Alan. ___ 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] Re: tuxkart, and bug reports..
On Thu, 13 Jun 2002, José Fonseca wrote: > > A system such as bugzilla can address everyone's needs (including Keith's > and Jens'). The way to address the needs of Keith and Jens is probably to let them ignore the bug tracking, and have others (maybe the originator, maybe just somebody else) track the things. People are different. Some people like coding and are good at it. Some people like having a system keep track of things for them. The two sets overlap somewhat, but most certainly aren't identical. I for example refuse to use anything that requires me to use a web browser and click around to update bugs. I feel that it's a complete waste of time. And sure, that has frustrated more than one kernel developer who wanted to know when something was fixed, or when some patch was applied, but the fact is, I've tried, and I just don't have the interest. And if I don't have the interest, it just won't get done. Which is why I understand Keith's reluctance very well. You shouldn't try to make developers work in some specific way - it's counterprodutive. Some people get tons of work done in the absolutely strangest ways possible. I know a kernel developer who use RCS (names withheld to protect the guilty), for Gods sake! In any sane society such a person would be instantly committed to the nearest insane asylum, but the fact is, he's _productive_. Some kernel developers don't even use a graphical desktop. Seriously. It wasn't more than a few days ago that Ingo Molnar complained that the kernel sources do not always fit on 80-character lines, and he still mostly uses 80x25 text mode. TEXT MODE! He's obviously crazy as a loon. But that's ok. He gets the work done. On a separate topic - have you guys thought about replacing the user mailing list with a real newsgroup? Yes, newsgroups are noisy as hell, but they are also fairly easy to browse through (especially with a scoring newsreader, or with the "D" key under trn). And the noisiness can be useful. Linus ___ 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] Re: tuxkart, and bug reports..
On 2002.06.13 17:19 Alan Hourihane wrote: > ... > > If Dieter is volunteering to go through it - then power to him... Alan, it's not as simple as that. Although it's very kind of him to volunteer, we all must get to a consensus before taking actions. Do you really think that that consensus exists? Then I ask again who [of the developers] compromises here that will indeed give answer to the bugs posted there? Please don't get me wrong. I'm just trying to avoid that history repeats - which I'm quite conviced that will happen. But in a couple of months time will say whether I'm right or wrong. Well, I have nothing more to say... I did hope that more developers shared their opinion though. I rest my case here. José Fonseca ___ 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] Re: tuxkart, and bug reports..
On Thu, Jun 13, 2002 at 05:52:59PM +0100, José Fonseca wrote: > On 2002.06.13 17:19 Alan Hourihane wrote: > >... > > > >If Dieter is volunteering to go through it - then power to him... > > Alan, it's not as simple as that. Although it's very kind of him to > volunteer, we all must get to a consensus before taking actions. > > Do you really think that that consensus exists? Then I ask again who [of > the developers] compromises here that will indeed give answer to the bugs > posted there? No - I don't think a consensus exists, and you probably won't get it. The people who want it, need to be willing to maintain it, and the people who don't - don't. But those people who are willing, need to maintain for those that don't too. If that's an unworkable situation, then we should close the bug tracking on sourceforge and force users to submit emails to dri-devel. That's something I can certainly agree with Keith on. Alan. ___ 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] Re: tuxkart, and bug reports..
On Thu, Jun 13, 2002 at 09:38:48AM -0700, Linus Torvalds wrote: > On a separate topic - have you guys thought about replacing the user > mailing list with a real newsgroup? Yes, newsgroups are noisy as hell, but > they are also fairly easy to browse through (especially with a scoring > newsreader, or with the "D" key under trn). And the noisiness can be > useful. I think that's forcing more software upon people to use. Everyone has email. And there'll probably be a reluctance by some to use newsreader software - thus hitting another problem. Alan. ___ 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] Re: tuxkart, and bug reports..
On Thursday 13 June 2002 19:01, Alan Hourihane wrote: > On Thu, Jun 13, 2002 at 05:52:59PM +0100, José Fonseca wrote: > > On 2002.06.13 17:19 Alan Hourihane wrote: > > >... > > > > > >If Dieter is volunteering to go through it - then power to him... > > > > Alan, it's not as simple as that. Although it's very kind of him to > > volunteer, we all must get to a consensus before taking actions. > > > > Do you really think that that consensus exists? Then I ask again who [of > > the developers] compromises here that will indeed give answer to the bugs > > posted there? > > No - I don't think a consensus exists, and you probably won't get it. > > The people who want it, need to be willing to maintain it, and the > people who don't - don't. But those people who are willing, need to > maintain for those that don't too. > > If that's an unworkable situation, then we should close the bug tracking > on sourceforge and force users to submit emails to dri-devel. > > That's something I can certainly agree with Keith on. Me too. -Dieter ___ 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] Re: tuxkart, and bug reports..
On 2002.06.13 17:38 Linus Torvalds wrote: > > You shouldn't try to make developers work in some specific way ... I wasn't. I was trying to avoid that a way which has shown just bad results so far was once more forced upon the developers, and at the same time suggesting what it seems (IMHO) the best compromise. I also don't think that letting everyone do as it pleases him is a good solution. For a month now I've been trying to answer to the problems on dri-users and in SF. Not only those that concern my development directly, but of others as well since I feel that everyone deserves an answer (even if he will never co-develop with us). I eventually quit on SF because it was impossible - sometimes I got a further reply, other times not, and it was all very awkard to use and nobody else seem to care. Now the same flawed solution is being put in pratice again. Anyway, I'm quite sure of myself. In the space of a couple of months I want to see where answers are being really given and by whom. Only then we'll know if we made the right choice or not. Personally I'll do the same I've been doing so far: trying to answer to the users' problems the best way I can and by any mean: dri-users/dri-devel/xpert/SFBT ... José Fonseca ___ 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] Broken context sharing/copying
Brian, do these tests look reasonable to you? We certainly shouldn't crash the server, even if they are unreasonable. Joe, can your try with the DRI CVS trunk? Joe Krahn wrote: > > I am trying to draw to two windows using one context. > It works for Mesa, but gives severe artifacts with DRI. > It would work to instead use glXCopyContext, but this > still doesn't work for DRI, and it crashes the server > with indirect rendering. > > I am using ATI Rage and Radeon, with XFree86 CVS. > Haven't tried DRI CVS yet, but I will do this soon. > > Here is a test app illustrating context bugs: > http://home.nc.rr.com/krahnfamily/source/cxbug.c > Aside from fixing bugs, any ideas on a workaround > to share a context in DRI? > > Another unrelated thing, not actually DRI: glDrawPixels > with GL_BITMAP and an incorrect format correctly gives an > error in DRI, but indirect results in an Xlib error: > http://home.nc.rr.com/krahnfamily/source/bitmap_bug.c > > Thanks, > Joe Krahn > > ___ > > 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 -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado ___ 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] Broken context sharing/copying
I intend to look into this problem, probably over the weekend. I've got at least one test program of my own to exercise this. Agreed, we shouldn't crash. -Brian Jens Owen wrote: > Brian, do these tests look reasonable to you? We certainly shouldn't > crash the server, even if they are unreasonable. > > Joe, can your try with the DRI CVS trunk? > > Joe Krahn wrote: > >>I am trying to draw to two windows using one context. >>It works for Mesa, but gives severe artifacts with DRI. >>It would work to instead use glXCopyContext, but this >>still doesn't work for DRI, and it crashes the server >>with indirect rendering. >> >>I am using ATI Rage and Radeon, with XFree86 CVS. >>Haven't tried DRI CVS yet, but I will do this soon. >> >>Here is a test app illustrating context bugs: >>http://home.nc.rr.com/krahnfamily/source/cxbug.c >>Aside from fixing bugs, any ideas on a workaround >>to share a context in DRI? >> >>Another unrelated thing, not actually DRI: glDrawPixels >>with GL_BITMAP and an incorrect format correctly gives an >>error in DRI, but indirect results in an Xlib error: >>http://home.nc.rr.com/krahnfamily/source/bitmap_bug.c >> >>Thanks, >>Joe Krahn ___ 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] tuxkart, and bug reports.. (David Willmore)
Howzit? > I see that there is a very active development community and three big projects > in the works (radeon, radeon T&L, and mach64). Yes I've slowly realise that this is what goes on in the DRI project, a thought has been rattling around in my head of late of a simple list of who is working on what project and more specifically what they are doing eg fixing bug xyz, adding feature abc, etc. That might make it easier for new developers who come along and say I want to help on xyz / abc and he can be referred to some one relevant. Might be a good idea to keep the list private, to prevent developers being swamped by email, bug reports, etc. Hey Jens? > 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. That's the plan it is progressing, although the guy doing the website itself is a little busy at the moment. > Update the web site. Having an almost undocumented web page with nightly > tarballs or anon CVS access is pretty user hostile. This is all part of the plan. > 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... ;) A loving developer - that defnitely counts me out. Liam it depends ___ 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] Understanding the internals of a X11/OpenGL Based Program (Using 3D Direct Rendering)
> > 1.) MK II: > > _ > > \ > > +-+ | > > | X11/OpenGL Based Application | | > > | (Using 3D Direct Rendering) | | > > +-+ | > > | | | > > V V | > > +--+ ++ | > > | OpenGL Library | | XLib | | > > +--+ ++ | > > | | | | | > > | | V | | Application > > | | +-+ | |--User > > | | | GLXLib | | |Process > > | | +-+ | | > > V || | | | > > +-+ VV | | | > > | OpenGL| ++ | | | > > | Renderer | | DRILib | | | | > > +-+ ++ | | | > > | | || | | | > > | V VV 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. > > Okay, but this is another example of where the number of arrows is just > plain confusing... nice play on words. First I want to get all the facts then I'll make it less plain and less confusing. It'll also be less confusing when I implement the alignment i was carry on about earlier. > > 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. > > The X Server case is a very cut and try case, and even it isn't really > implemented that way. All I'm trying to convey here is arrows can't > tell the whole story, so we can't put an exact definition on what an > arrow really means. Consequently, I can't give you detailed and precise > feedback on how to make the arrows and boxes should look. > > So, use your judgement as to which looks prettier :-) It's an abstraction, it'll never mirror reality perfectly. I'm going to be doing some reading, if that resolves it I wont have to bother you about this again 3.) > We need access to X Server internal data structures that the kernel > doesn't have. So the X Server cant handle its resources independantly, it must co-operate / co-ordinate with DRI? ie X Server talks to kernel on its own, what does it do when there is no DRI? > I believe the resource management example we looked at was window offset > and cliplist. Window cliplists are controlled and updated by the X > Server. Every time a window is moved, the X Server recomputes clip > lists for all affected windows. The 3DDRP has to get this information > from the X Server somehow. OK this could be a gross oversimplification but if I understand correctly there are two RM paths, one for 3D (3DDRP DRM Lib) and one one for 2D (X Server DRM Lib). Liam it depends ___ 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] Re: tuxkart, and bug reports..
Alan Hourihane wrote: > On Thu, Jun 13, 2002 at 04:20:47PM +0100, José Fonseca wrote: > >>On 2002.06.13 15:43 Alan Hourihane wrote: >> >>>... >>> >>>What would be great, is if someone assigned the bugs to relevant >>>developers. Once someone is assigned to the bug report, they get >>>emails whenever it's updated. But that someone needs to know who >>>to charge with that bug report. >>> >>>Someone who would standup to maintain it would be GREAT! >>> >>>Alan. >>> >>That person's time would be better spent by setting up a _real_ bug >>tracking system, where this would be done automatically, such as bugzilla >>or the debian one. >> >>I know that usually the saying is the other way around but... "we >>shouldn't have a person doing a machine's job"! >> > > What I'm afraid might happen with setting up something like bugzilla, > is the much more severe maintenance of it. If that person where to > walk away from the project, we're much more stuck that where we are > now with SF. O.k. I admit that the SF system is primitive, but it > works without too much maintenance. It's just that we (as developers) > aren't using it at all. And that's down to us. It's not that I'm being lazy when I say I don't want to use it. First of all, if someone has a bug they want me to fix, they should stick around long enough to have an email conversation about it. I'm doing free work for them, if I decide/am able to fix the bug, after all. The bug tracker gets in the way of any communication between me & the guy with the bug. It adds useless work in terms of logging into sf, fighting with their dumb web frontend, and whatever, every time I want to talk to the other person. Then, worst of all, once I fix the bug I have to go in and tell the damn thing that it's fixed. Why bother? The other guy presumably already knows, having been involved throughout... Keith ___ 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
[Dri-users] Re: [Dri-devel] Mach64 2D accel fixed!
>The challenge with back and depth buffers is being able to allocate >additional space on the fly (when a window is resized for example). We >chose a static allocation method over shutting down the application >after it's already been running. If a good mechanism can be devised for >addressing that failure case, then it would be possible to consider >private back and depth buffers for multiple 3D windows. How about, "if there isn't enough VRAM, fall back to software rendering"? That's what Apple's implementation does, or at least used to. -- -- from: Jonathan "Chromatix" Morton mail: [EMAIL PROTECTED] (not for attachments) website: http://www.chromatix.uklinux.net/ geekcode: GCS$/E dpu(!) s:- a21 C+++ UL++ P L+++ E W+ N- o? K? w--- O-- M++$ V? PS PE- Y+ PGP++ t- 5- X- R !tv b++ DI+++ D G e+ h+ r++ y+(*) tagline: The key to knowledge is not to rely on people to teach you it. ___ 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
[Dri-devel] BUG: Mach64 20020613 -- lock in gltestperf
So, I downloaded the newest mach64 code and installed it. After fighting with the drm not loading automatically, and the bit depth being too high *smack*, I got direct rendering working! :) ~250 fps on glxgears is spiffy-- beats ~60 without DRI. With that behind me, I decided to get brave. So, I searched /usr/bin for all binaries which link agains libGL. Got quite a list. Did a for i in `cat list`; do sh -c $i; done and walked through them. Some silly ones seem to not run due to lack of resources--they weren't specific, but who cares? Fire is sort of cool, but I digress. Get down to gltestperf and things start to get ugly. It runs through drawing some lines of different lengths and then does some triangles. Here it blabs something and says that if I have a 3dfx card, I need to run the benchmark as root. It also says something about pressing to continue and about needing to move the mouse. Very shortly thereafter, it gets slugish and everything slowly grinds to a halt. At this point, nothing gets its attention. I don't have remote access turned on, so I don't have any logs of what happened--though I have little doubt that I can reproduce it. So, before I setup logging, what logging/information would you like to see? Here's the basic info: Linux 2.4.18(homebuilt) Base Distro RH7.1 Machine: NEC Versa LX 400 MHZ PII(mobile) BX/ZX based AGP chipset Rage LT Pro AGP133 rev 220 w/8M 16 bit color depth *smack* XFree86 v4.2 Oh, little question: is 2D accell off when 3D is on? I noticed the times that I failed to get 3D accel on, the 2D was nice and snappy. Once 3D was on, 2D acted like it did in older version where there was no 2D accel. Mozilla is *painful* without it. Flash doesn't even *work*. :( I'm willing to lose Xv, but 2D accel is too much. :) Great work, though, on the 3D! Cheers, David ___ 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] Re: tuxkart, and bug reports..
--- Alan Hourihane <[EMAIL PROTECTED]> wrote: > On Thu, Jun 13, 2002 at 09:38:48AM -0700, Linus Torvalds wrote: > > On a separate topic - have you guys thought about replacing the user > > mailing list with a real newsgroup? Yes, newsgroups are noisy as hell, but > > they are also fairly easy to browse through (especially with a scoring > > newsreader, or with the "D" key under trn). And the noisiness can be > > useful. > > I think that's forcing more software upon people to use. Everyone > has email. And there'll probably be a reluctance by some to use > newsreader software - thus hitting another problem. > > Alan. > I would be in this group, I don't currently use news. --- Brian Paul <[EMAIL PROTECTED]> wrote: > > Just to put in my two cents: > > 1. On the bug database: > > Using the SF bug database is a real hassle, and it's not that good. > I'd rather see bug reports come to the devel mailing list. It would > be far more effective. The same goes for the patch manager and > feature/support-request trackers. > > When someone files a bug report anonymously there's almost zero chance > of it getting resolved since the anonymous poster never replies to the > inevitable follow-up questions. > I don't see how I can help there, I looked at it and it is a mess. If it where cleaned up I could keep an eye on it and try to help it grow. > > 2. On mailing lists: > > I've never suscribed to the dri-users list. I spend enough time as it > is monitoring the mail on dri-devel. Like the other developers, I > think my time is better spent on the high-profile problems, rather > than answering newbie questions. So I guess I'd like to see us > continue with separate lists and hope that people use them appropriately. > > -Brian > I'm on the dri-users and now that I know that I need to be answering users questions there, I think I can make it a happier place. --- Alan Hourihane <[EMAIL PROTECTED]> wrote: > On Thu, Jun 13, 2002 at 04:03:05PM +0100, Keith Whitwell wrote: > > Understood, but there's a lot of users out there that don't want > to receive emails from dri-devel. They just want to submit a bug, > walk away, then get some response back to say it's fixed, or someone's > working on it, or it won't be fixed etc. > > But with the SF bug tracking system we are currently sending bug > reports, patches etc to the dri-patches mailing list. Maybe we should > re-route them to dri-devel to get more feedback. > I'd be able to better help ought if they went to dri-users, I could then forward ones to dri-devel if needed. As mentioned erlier I think there are some power-users ought there, at least one :) I don't think I want to subscribe to dri-patches, I don't think it's the place for bug reports... at all. > The problem we're facing is that there's no formal process to assigning > the bug report, so no-one else knows whether someone could be working > on it or not, thus duplicating effort. > > Development is ideally what we all want to be doing, but there's a > few admin type tasks we really do have to bear - and that's the uphill > struggle. > > Alan. > I'd be happy to help ought with some admin type tasks. __ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com ___ 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
[Dri-devel] memory leak (?)
i recently switched over to the trunk of dri since tcl branch is pretty much no more and after switching over i seem to of found a rather nasty bug it might of been there before cause i never really did test the tcl branch as long as i was playing with the trunk today anyways after playing ut for some time (5-10m) on a level that has a rather large area the fps drop say from ~27fps to ~4fps in 5m on a level i have that is rather large ctf-face droped from i think ~100fps(during spectator mode before match) to ~19fps looking at the same place with out any bots shown after ~5m i think it was having pageflipping enabled seems to speed up the time it takes to drop the frame rate. also with pageflipping enabled ut and a psx emulator seems to be more jerky not as smooth a frame rate this is a radeon 7500 on a amd athlon 850 and running agp at 2x if that makes a difference (a friend said that ut was a little jerky for him also on same branch with a radeon vivo i think it was) if any more information is needed just ask also if needed i can try and debug this but i will need to know what to debug ___ 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
