Re: [Dri-devel] Fallback in radeon_Materialfv() doesnt work
unfortunately it was only a partial fix
(but was enough for that particular program)
heres a new one: (and maybe it should be handeld this way
with GL_QUAD_STRIP, too)
--- radeon_vtxfmt.c_origFri Mar 21 17:22:23 2003
+++ radeon_vtxfmt.c Tue Mar 25 07:45:52 2003
@@ -312,7 +312,14 @@
return 2;
}
case GL_TRIANGLE_STRIP:
- ovf = MIN2( nr-1, 2 );
+ if (nr == 0) /* dont let verts go negative! */
+ return 0;
+ if (nr == 1) /* copy the right one ? */
+ ovf = 1;
+ else if (nr == 2) /* copy 2 verts, not only one */
+ ovf = 2;
+ else
+ ovf = MIN2( nr-1, 2 );
for (i = 0 ; i < ovf ; i++)
copy_vertex( rmesa, nr-ovf+i, tmp[i] );
return i;
could that be a bit faster in the hole thing?
--- radeon_vtxfmt.c Tue Mar 25 07:57:34 2003
+++ radeon_vtxfmt.c_origFri Mar 21 17:22:23 2003
@@ -312,17 +312,7 @@
return 2;
}
case GL_TRIANGLE_STRIP:
- if (nr < 3)
- {
- if (nr == 2) /* copy 2 verts, not only one */
-ovf = 2;
- else if (nr == 1) /* copy the right one ? */
-ovf = 1;
- else /* nr==0: dont let verts go negative! */
-return 0;
- }
- else
- ovf = MIN2( nr-1, 2 );
+ ovf = MIN2( nr-1, 2 );
for (i = 0 ; i < ovf ; i++)
copy_vertex( rmesa, nr-ovf+i, tmp[i] );
return i;
Am 2003.03.24 22:13:12 +0100 schrieb(en) Keith Whitwell:
Andreas Stenglein wrote:
this patch helps for the demo.
but someone more familiar with radeon_vtxfmt should
check if it really fixes all cases...
I think in case of GL_QUAD_STRIP we should check
for 0, too.
(and maybe for 1?)
--- radeon_vtxfmt.c_origFri Mar 21 17:22:23 2003
+++ radeon_vtxfmt.cMon Mar 24 21:52:58 2003
@@ -312,6 +312,8 @@
return 2;
}
case GL_TRIANGLE_STRIP:
+ if (nr == 0) /* dont let verts go negative! */
+ return 0;
ovf = MIN2( nr-1, 2 );
for (i = 0 ; i < ovf ; i++)
copy_vertex( rmesa, nr-ovf+i, tmp[i] );
Good catch!
I'll commit fixes for this.
Keith
---
This SF.net email is sponsored by:
The Definitive IT and Networking Event. Be There!
NetWorld+Interop Las Vegas 2003 -- Register today!
http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] XFree86-4.3 DRI and kernel-2.5.X
Is their anyway I can get a diff for XFree86-4.3 DRI against 2.5.latest? I'm starting to play with this kernel and want dri working for my radeon. --Lou --- This SF.net email is sponsored by: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] performance oddities
DUDE! I was wondering what the environment variable was!!! Thanks a million! On Mon, 24 Mar 2003 04:39 pm, Ian Romanick wrote: > MichaelM wrote: > > GLX extensions: > > GLX_ARB_get_proc_address, GLX_EXT_import_context, > > GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_agp_offset, > > GLX_MESA_swap_control, GLX_NV_vertex_array_range, GLX_SGI_video_sync > > You didn't say you were running the texmem branch. It's only running at > 80fps because it's synced to the vertical refresh. Set the environment > variable LIBGL_NO_VSYNC=1 and try it. > > > > --- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > ___ > Dri-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/dri-devel --- This SF.net email is sponsored by: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] 4.3.0 merge
On Mon, Mar 24, 2003 at 04:22:11PM -0700, Jens Owen wrote: > Keith Whitwell wrote: > >Alan Hourihane wrote: > > > >>I'm going to start the 4.3.0 merge. Be prepared for breakage. > >> > >>I'll post another followup when I'm finished. > > > > > >Thanks for doing this, Alan. > > Definitely. Thanks, Alan. No problems. But it's late here now, and my ISDN connection is sucking down the tree to resolve the conflicts now. I'll finish up tomorrow, sorry for the build bustage for now. Alan. --- This SF.net email is sponsored by: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Reasons for "current context" and "current dispatch table"
On Sat, Mar 22, 2003 at 07:24:15PM +, José Fonseca wrote: | Also, I can't help thinking that some of these tricks wouldn't be | necessary if the OpenGL standard had chosen to pass opaque pointers | (i.e., handles) to contexts and textures, instead of using concepts such | as "current context" and "texture names", but this is OT anyway. The history behind the design goes something like this. 3D drawing operations require a lot of state information. (Much more than is typical for OS I/O services or 2D graphics.) In the Olden Days fast memory was hideously expensive, so there wasn't much hardware support for multiple sets of state. It made sense to expose the state to the application, which could then help minimize the number of unnecessary state changes. It also made sense to design the API so that it was hard for app developers to accidentally invoke expensive state updates or update optimizations. If the API had been designed to pass a "current context" handle as an argument to each OpenGL command, the OpenGL library would have to detect when a new context had been used, then "diff" the current and new contexts to generate an efficient set of state updates. Just checking a cache for the context used on the last command involves a fetch from thread-local storage, and state-diffing is a pretty slow process. A better approach seemed to be to fetch the current context from thread-local storage in the first place, and isolate state-diffing to a relatively heavyweight "context change" operation that would have to be requested explicitly. The current-context approach and the separate dispatch table were both influenced by experience with X11, which itself was influenced by experience with early versions of Windows. (And other systems that I don't recall at the moment.) In retrospect, it might have been nice to expose the dispatch table to the application (perhaps like COM interfaces). That could eliminate one level of indirection and it might handle extensions more cleanly. But it introduces new problems, and I'm not sure about the tradeoffs. Allen --- This SF.net email is sponsored by: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] 4.3.0 merge
Jens Owen <[EMAIL PROTECTED]> wrote: > Keith Whitwell wrote: >> Alan Hourihane wrote: >> >>> I'm going to start the 4.3.0 merge. Be prepared for breakage. >>> >>> I'll post another followup when I'm finished. >> >> >> Thanks for doing this, Alan. > Definitely. Thanks, Alan. Oh yes, this way we'll have "best of both worlds". I'm sort of happy about this, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- This SF.net email is sponsored by: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] 4.3.0 merge
Keith Whitwell wrote: Alan Hourihane wrote: I'm going to start the 4.3.0 merge. Be prepared for breakage. I'll post another followup when I'm finished. Thanks for doing this, Alan. Definitely. Thanks, Alan. -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] 4.3.0 merge
Alan Hourihane wrote: I'm going to start the 4.3.0 merge. Be prepared for breakage. I'll post another followup when I'm finished. Thanks for doing this, Alan. Keith --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] 4.3.0 merge
I'm going to start the 4.3.0 merge. Be prepared for breakage. I'll post another followup when I'm finished. Alan. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Network Uzmaný olun (Yeni bir kariyer)
Geleceği bizimle yakalayın. Dünyayı elinize alabilmek için artı değeriniz olmalı. Gelin bu değeri Network uzmanı olarak bizden elde edin. http://www.mcseteam.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Fallback in radeon_Materialfv() doesnt work
this patch helps for the demo. but someone more familiar with radeon_vtxfmt should check if it really fixes all cases... I think in case of GL_QUAD_STRIP we should check for 0, too. (and maybe for 1?) --- radeon_vtxfmt.c_origFri Mar 21 17:22:23 2003 +++ radeon_vtxfmt.c Mon Mar 24 21:52:58 2003 @@ -312,6 +312,8 @@ return 2; } case GL_TRIANGLE_STRIP: + if (nr == 0) /* dont let verts go negative! */ + return 0; ovf = MIN2( nr-1, 2 ); for (i = 0 ; i < ovf ; i++) copy_vertex( rmesa, nr-ovf+i, tmp[i] ); best regards, Andreas --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Fallback in radeon_Materialfv() doesnt work
Andreas Stenglein wrote: this patch helps for the demo. but someone more familiar with radeon_vtxfmt should check if it really fixes all cases... I think in case of GL_QUAD_STRIP we should check for 0, too. (and maybe for 1?) --- radeon_vtxfmt.c_origFri Mar 21 17:22:23 2003 +++ radeon_vtxfmt.cMon Mar 24 21:52:58 2003 @@ -312,6 +312,8 @@ return 2; } case GL_TRIANGLE_STRIP: + if (nr == 0) /* dont let verts go negative! */ + return 0; ovf = MIN2( nr-1, 2 ); for (i = 0 ; i < ovf ; i++) copy_vertex( rmesa, nr-ovf+i, tmp[i] ); Good catch! I'll commit fixes for this. Keith --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Weekly IRC meeting reminder
This is just a friendly reminder that the weekly dri-devel IRC meeting will be starting in the #dri-devel channel on irc.freenode.net at 2100 UTC (or 4:00PM EST or 1:00PST, if you prefer). Time zone conversion available at: http://www.timezoneconverter.com/cgi-bin/tzc.tzc Logs of previous IRC meetings are available at: http://dri.sourceforge.net/IRC-logs/ --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] i810 sharing interrupts race condition..
It looks fine to me, though I can't test it myself. Even if it doesn't completely fix the problem, I think it's the 'Right Thing' to do. I've committed the i810/i830_dri.c fix to the DRI trunk (I also added the drmCtlUninstHandler symbol to the referenced symbol list in i810_driver.c). If someone can verify that this fix works with a Linux 2.4.x drm module, I can submit this to XFree86 as well for the 4.3.x branch. OK, I can put an i810 box together once I get a bit of spare time (tomorrow, hooray). Keith --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] i810 sharing interrupts race condition..
On Mon, 24 Mar 2003, Keith Whitwell wrote: > Leif Delgass wrote: > > On Mon, 24 Mar 2003, Keith Whitwell wrote: > > > > > >>Dave Airlie wrote: > >> > >>>I've just had the misfortune of having my NFSROOT system (lots of network > >>>interrupts), have its card sharing interrupts with the i810 graphics.. > >>>once I run anything 3d the kernel oops.. > >>> > >>>The attached patch contains the quick fix which is to check in thr irq > >>>handler if dev->dev_private is NULL or not before going using it .. also a > >>>udelay patch included which I think the DRI tree has but the LK one > >>>doesn't(arrgg too many trees :-).. > >>> > >>>I've attached a second patch to > >>>xc/xc/programs/Xserver/hw/xfree86/drivers/i810/i810_dri.c that may also > >>>fix the problem but which I haven't tested, > >>> > >>>What happens is the DMA cleanup occurs which frees the private data, and > >>>an interrupt comes in from the network card most likely but the i810 > >>>driver is let know as the IRQ hasn't been deregistered yet.. > >>> > >>>This issue also will affect the i830 and gamma (not that anyone cares) but > >>>maybe others as well as my DRI tree is old enough at this stage > >> > >>What codebase is this patch against? I was of the opinion that we'd actually > >>eliminated the use of interrupts from the i810 driver. > >> > >>Keith > > > > > > It looks like the i810 and i830 drm modules in the 2.4.x kernel tree still > > use interrupts. > > Oh, wow. > > > In any case, I think the patch against i810/i830_dri.c > > should be applied so we have a drmCtlUninstHandler to match the > > drmCtlInstHandler -- which is there for backward compatibility with older > > drm modules. Also, this would be used if vblank support is added for > > i810/i830. > > I'm well snowed under right now - can you commit this if it looks right? > > Keith It looks fine to me, though I can't test it myself. Even if it doesn't completely fix the problem, I think it's the 'Right Thing' to do. I've committed the i810/i830_dri.c fix to the DRI trunk (I also added the drmCtlUninstHandler symbol to the referenced symbol list in i810_driver.c). If someone can verify that this fix works with a Linux 2.4.x drm module, I can submit this to XFree86 as well for the 4.3.x branch. -- Leif Delgass http://www.retinalburn.net --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: hi
http://www.quickleadz.bz/mort/short/ Hi, I just got a 30 year fixed mortgage at 4.75%. I found this website where Lenders compete for your business. I thought you may want to look at it. http://www.quickleadz.bz/mort/short/ Thanks, William Burton Remove: http://www.quickleadz.bz/mort/rem/ --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] i810 sharing interrupts race condition..
On Mon, 24 Mar 2003, Keith Whitwell wrote: > Dave Airlie wrote: > > I've just had the misfortune of having my NFSROOT system (lots of network > > interrupts), have its card sharing interrupts with the i810 graphics.. > > once I run anything 3d the kernel oops.. > > > > The attached patch contains the quick fix which is to check in thr irq > > handler if dev->dev_private is NULL or not before going using it .. also a > > udelay patch included which I think the DRI tree has but the LK one > > doesn't(arrgg too many trees :-).. > > > > I've attached a second patch to > > xc/xc/programs/Xserver/hw/xfree86/drivers/i810/i810_dri.c that may also > > fix the problem but which I haven't tested, > > > > What happens is the DMA cleanup occurs which frees the private data, and > > an interrupt comes in from the network card most likely but the i810 > > driver is let know as the IRQ hasn't been deregistered yet.. > > > > This issue also will affect the i830 and gamma (not that anyone cares) but > > maybe others as well as my DRI tree is old enough at this stage > > What codebase is this patch against? I was of the opinion that we'd actually > eliminated the use of interrupts from the i810 driver. > > Keith It looks like the i810 and i830 drm modules in the 2.4.x kernel tree still use interrupts. In any case, I think the patch against i810/i830_dri.c should be applied so we have a drmCtlUninstHandler to match the drmCtlInstHandler -- which is there for backward compatibility with older drm modules. Also, this would be used if vblank support is added for i810/i830. -- Leif Delgass http://www.retinalburn.net --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] performance oddities
MichaelM wrote: GLX extensions: GLX_ARB_get_proc_address, GLX_EXT_import_context, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_agp_offset, GLX_MESA_swap_control, GLX_NV_vertex_array_range, GLX_SGI_video_sync You didn't say you were running the texmem branch. It's only running at 80fps because it's synced to the vertical refresh. Set the environment variable LIBGL_NO_VSYNC=1 and try it. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] i810 sharing interrupts race condition..
Dave Airlie wrote: I've just had the misfortune of having my NFSROOT system (lots of network interrupts), have its card sharing interrupts with the i810 graphics.. once I run anything 3d the kernel oops.. The attached patch contains the quick fix which is to check in thr irq handler if dev->dev_private is NULL or not before going using it .. also a udelay patch included which I think the DRI tree has but the LK one doesn't(arrgg too many trees :-).. I've attached a second patch to xc/xc/programs/Xserver/hw/xfree86/drivers/i810/i810_dri.c that may also fix the problem but which I haven't tested, What happens is the DMA cleanup occurs which frees the private data, and an interrupt comes in from the network card most likely but the i810 driver is let know as the IRQ hasn't been deregistered yet.. This issue also will affect the i830 and gamma (not that anyone cares) but maybe others as well as my DRI tree is old enough at this stage What codebase is this patch against? I was of the opinion that we'd actually eliminated the use of interrupts from the i810 driver. Keith --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
