[Dri-devel] Re: different build options for alpha
On 7 Feb 2003, Michel Dänzer wrote: Someone sent me this patch to build my Debian packages on alpha. Is there any reason not to apply it to the trunk? Yes. Applying it would be similar to adding the following to the trunk for x86: DefaultGcc2i386Opt -march=i686 -mcpu=i686 In other words, it would make the default build run only on EV56 Alpha machines or higher. There are a great many EV5 machines out there, and most people I encounter running Alpha (such as on #alpha on freenode) are using EV5 boxen. Please don't apply this to the default build, it is something that someone should add as an architecture customization IMHO. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: different build options for alpha
On 7 Feb 2003, Michel Dänzer wrote: Date: 07 Feb 2003 00:04:59 +0100 From: Michel Dänzer [EMAIL PROTECTED] To: [EMAIL PROTECTED] Content-Type: multipart/mixed; boundary==-VHm8nTy1q66jRspvQ0H6 List-Id: dri-devel.lists.sourceforge.net Subject: different build options for alpha Someone sent me this patch to build my Debian packages on alpha. Is there any reason not to apply it to the trunk? Oops.. I misread your patch. It does -mcpu=ev56 and not -march=ev56, so it would still run on any alpha. My bad. As a total guess, most businesses probably have EV56 or higher in usage, however I'd also guess most hobbiests have EV5 machines, so choosing a default instruction scheduling that is representative of the majority out there would be tricky. I'm using EV67 here, so either will work for me. ;o) It might be best to stick with the lowest common denominator perhaps. TTYL -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] different build options for alpha
On Fri, Feb 07, 2003 at 02:24:26 +0100, Michel Dänzer wrote: On Fre, 2003-02-07 at 01:53, Alan Hourihane wrote: On Fri, Feb 07, 2003 at 01:49:29AM +0100, Michel Dnzer wrote: On Fre, 2003-02-07 at 00:19, Alan Hourihane wrote: On Fri, Feb 07, 2003 at 12:04:59AM +0100, Michel Dnzer wrote: Someone sent me this patch to build my Debian packages on alpha. Is there any reason not to apply it to the trunk? Technically we shouldn't be compiling with any CPU options. So I'm o.k. with removing them for all architectures. Remove it all then, like this? Yeah, that's it. But I'm thinking more to comment them out now, so people now how to set them up if need be without having to remember what it was to optimize things. Like this then? :) Yup. Alan. --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: missing xf86strtof definition
On Fri, Feb 07, 2003 at 09:33:22AM +0300, Konstantin Lepikhov wrote: Friday 07, at 01:06:22 AM you wrote: Good catch. Just committed a fix for it. Alan. Now dri-trunk not compile Oops. cutpaste error. fixed. Alan. --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Viagra - Phentermine - Xenical - Propecia and MORE. nget
Welcome
to the most reliable U.S. company to dispense FDA approved medications
online!
weight loss
women's health
men's health
sexual health
skincare
pain relief stop smoking
Prescribed by licensed U.S.
Physicians, dispensed by U.S. Pharmacies!
Find Lower Prices, a Safe Secure
experience, Fast
Delivery and Real Time order tracking!
Visit Us Here!
Your privacy is extremely
important
to us. You requested to receive this mailing by subscribing to one or more
of
our offers or through one of our marketing partners. As a leader in email
marketing, We are committed to delivering a highly
rewarding experience, with offers that include bargains, entertainment, and
money-making ideas. However, if you wish to unsubscribe,
Press here
Third-party offers
contained in this email are the sole responsibility of the offer
originator.
{{x0}}
aw q nemgsnnigmmsrs
otmzvfryl
Re: [Dri-devel] textures lock system
On Fre, 2003-02-07 at 08:42, Chris Ison wrote: ok, after a system upgrade, a cvs up and a compile for the new system, dri trunk has a weird problem. when ever a gl app tries to use textures, the system locks, glxgears runs fine, x11perf runs fine till it hits the texture tests then locks. What do you mean? My x11perf doesn't do texture tests, nor any 3D tests for that matter. System is now a p2 350, Radeon 9000 pci, yes the board has AGP and agpgart is compiled for the kernel. Note: no errors on boot, and some straces show nothing out of the ordinary before the lock. I assume the radeon driver fails to initialize agpgart? -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: different build options for alpha
On Fre, 2003-02-07 at 09:13, Mike A. Harris wrote: On 7 Feb 2003, Michel Dänzer wrote: Someone sent me this patch to build my Debian packages on alpha. Is there any reason not to apply it to the trunk? Oops.. I misread your patch. It does -mcpu=ev56 and not -march=ev56, so it would still run on any alpha. My bad. I think you still haven't looked at the patch carefully... there's been -mcpu=ev6 in there for as long as I remember, which breaks on the ev56 machine of the person who sent me that patch. I committed the solution discussed with Alan now. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: different build options for alpha
On 7 Feb 2003, Michel Dänzer wrote: Someone sent me this patch to build my Debian packages on alpha. Is there any reason not to apply it to the trunk? Oops.. I misread your patch. It does -mcpu=ev56 and not -march=ev56, so it would still run on any alpha. My bad. I think you still haven't looked at the patch carefully... there's been -mcpu=ev6 in there for as long as I remember, which breaks on the ev56 machine of the person who sent me that patch. I committed the solution discussed with Alan now. Gah.. typo.. my brain isn't with me today... -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] missing xf86strtof definition
Alan Hourihane wrote: On Fri, Feb 07, 2003 at 01:06:22AM +, Alan Hourihane wrote: On Fri, Feb 07, 2003 at 10:55:33AM +1000, Chris Ison wrote: in XFree86 log Symbol xf86strtof from module /usr/X11R6/lib/modules/extensions/libGLcore.a is unresolved! this function doesn't exist in XFree86 trunk, nor DRI trunk (going by grep), how ever it is used in extras/Mesa/src/imports.c did someone forget to commit its definition? Good catch. Just committed a fix for it. Mmmm. Looking at Mesa though, it doesn't define it's wrapper interface for strtof() either, and I can't see it being used within Mesa too. It's wrapping calls xf86strtof() or strtod() - is that intentional ? or... Should this be removed from imports.c ? AFAIK, I've never used strtof/strtod in Mesa until in the current 5.1/trunk code. I need it for fragment program parsing. Looks like some of the 5.1 code was merged into the DRI tree by Ian. He probably did that to get the ATI_texture_env_combine3 code. Just a warning: the Mesa 5.1 code is subject to lots of change/breakage/etc since it's not a stable branch. Pulling it into the DRI trunk is a bit risky. -Brian --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: different build options for alpha
Michel Dänzer wrote: On Fre, 2003-02-07 at 09:13, Mike A. Harris wrote: On 7 Feb 2003, Michel Dänzer wrote: Someone sent me this patch to build my Debian packages on alpha. Is there any reason not to apply it to the trunk? Oops.. I misread your patch. It does -mcpu=ev56 and not -march=ev56, so it would still run on any alpha. My bad. I think you still haven't looked at the patch carefully... there's been -mcpu=ev6 in there for as long as I remember, which breaks on the ev56 machine of the person who sent me that patch. If setting a -mcpu option actually breaks the compiled program for a different CPU in the same family, then it is a bug in GCC or a bug in the program. The -mcpu options are only supposed to change how instructions are scheduled, not which version of the ISA is used. It would be like if compiling with -O1 worked, but -O2 caused a crash. --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] textures lock system
Chris Ison wrote: ok, after a system upgrade, a cvs up and a compile for the new system, dri trunk has a weird problem. when ever a gl app tries to use textures, the system locks, glxgears runs fine, x11perf runs fine till it hits the texture tests then locks. System is now a p2 350, Radeon 9000 pci, yes the board has AGP and agpgart is compiled for the kernel. Note: no errors on boot, and some straces show nothing out of the ordinary before the lock. Could you send your XFree86 log? I suppose it's possible that it's still trying to use AGP to transfer data. Is PCIGART enabled? --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] missing xf86strtof definition
On Fri, Feb 07, 2003 at 10:55:33AM +1000, Chris Ison wrote: in XFree86 log Symbol xf86strtof from module /usr/X11R6/lib/modules/extensions/libGLcore.a is unresolved! this function doesn't exist in XFree86 trunk, nor DRI trunk (going by grep), how ever it is used in extras/Mesa/src/imports.c did someone forget to commit its definition? strtof isn't very portable (C99), so something else should be used (maybe sscanf, for example). David -- David Dawes Release Engineer/Architect The XFree86 Project www.XFree86.org/~dawes --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] missing xf86strtof definition
On Fri, Feb 07, 2003 at 07:27:42AM -0700, Brian Paul wrote: Alan Hourihane wrote: On Fri, Feb 07, 2003 at 01:06:22AM +, Alan Hourihane wrote: On Fri, Feb 07, 2003 at 10:55:33AM +1000, Chris Ison wrote: in XFree86 log Symbol xf86strtof from module /usr/X11R6/lib/modules/extensions/libGLcore.a is unresolved! this function doesn't exist in XFree86 trunk, nor DRI trunk (going by grep), how ever it is used in extras/Mesa/src/imports.c did someone forget to commit its definition? Good catch. Just committed a fix for it. Mmmm. Looking at Mesa though, it doesn't define it's wrapper interface for strtof() either, and I can't see it being used within Mesa too. It's wrapping calls xf86strtof() or strtod() - is that intentional ? or... Should this be removed from imports.c ? AFAIK, I've never used strtof/strtod in Mesa until in the current 5.1/trunk code. I need it for fragment program parsing. Hmm.. does this mean Mesa is going to have ARB_f_p support (in software?) ? How about ARB_v_p ? -- Pasi Kärkkäinen ^ . . Linux /-\ Choice.of.the .Next.Generation. --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] missing xf86strtof definition
Pasi Kärkkäinen wrote: On Fri, Feb 07, 2003 at 07:27:42AM -0700, Brian Paul wrote: Alan Hourihane wrote: On Fri, Feb 07, 2003 at 01:06:22AM +, Alan Hourihane wrote: On Fri, Feb 07, 2003 at 10:55:33AM +1000, Chris Ison wrote: in XFree86 log Symbol xf86strtof from module /usr/X11R6/lib/modules/extensions/libGLcore.a is unresolved! this function doesn't exist in XFree86 trunk, nor DRI trunk (going by grep), how ever it is used in extras/Mesa/src/imports.c did someone forget to commit its definition? Good catch. Just committed a fix for it. Mmmm. Looking at Mesa though, it doesn't define it's wrapper interface for strtof() either, and I can't see it being used within Mesa too. It's wrapping calls xf86strtof() or strtod() - is that intentional ? or... Should this be removed from imports.c ? AFAIK, I've never used strtof/strtod in Mesa until in the current 5.1/trunk code. I need it for fragment program parsing. Hmm.. does this mean Mesa is going to have ARB_f_p support (in software?) ? How about ARB_v_p ? Mesa has NV_vertex_program and I'm (slowly) working on NV_fragment_program. They're a bit simpler to implement than the ARB-flavor of those extensions. I'd be happy to get volunteers to help implement the ARB_*_program extensions. -Brian --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] missing xf86strtof definition
David Dawes wrote: On Fri, Feb 07, 2003 at 10:55:33AM +1000, Chris Ison wrote: in XFree86 log Symbol xf86strtof from module /usr/X11R6/lib/modules/extensions/libGLcore.a is unresolved! this function doesn't exist in XFree86 trunk, nor DRI trunk (going by grep), how ever it is used in extras/Mesa/src/imports.c did someone forget to commit its definition? strtof isn't very portable (C99), so something else should be used (maybe sscanf, for example). Thanks for the tip - I may make that change. -Brian --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] missing xf86strtof definition
On Fri, Feb 07, 2003 at 11:26:53AM -0500, David Dawes wrote: On Fri, Feb 07, 2003 at 08:36:27AM -0700, Brian Paul wrote: David Dawes wrote: On Fri, Feb 07, 2003 at 10:55:33AM +1000, Chris Ison wrote: in XFree86 log Symbol xf86strtof from module /usr/X11R6/lib/modules/extensions/libGLcore.a is unresolved! this function doesn't exist in XFree86 trunk, nor DRI trunk (going by grep), how ever it is used in extras/Mesa/src/imports.c did someone forget to commit its definition? strtof isn't very portable (C99), so something else should be used (maybe sscanf, for example). Thanks for the tip - I may make that change. Well, xf86strtof() won't be available in any XFree86 release in the forseeable future, and the changes that added it in the DRI tree should be backed out so that nothing else comes to rely on it. Ah, o.k. strtod is o.k. - strtof isn't. Alan. --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] missing xf86strtof definition
Alan Hourihane wrote: On Fri, Feb 07, 2003 at 11:26:53AM -0500, David Dawes wrote: On Fri, Feb 07, 2003 at 08:36:27AM -0700, Brian Paul wrote: David Dawes wrote: On Fri, Feb 07, 2003 at 10:55:33AM +1000, Chris Ison wrote: in XFree86 log Symbol xf86strtof from module /usr/X11R6/lib/modules/extensions/libGLcore.a is unresolved! this function doesn't exist in XFree86 trunk, nor DRI trunk (going by grep), how ever it is used in extras/Mesa/src/imports.c did someone forget to commit its definition? strtof isn't very portable (C99), so something else should be used (maybe sscanf, for example). Thanks for the tip - I may make that change. Well, xf86strtof() won't be available in any XFree86 release in the forseeable future, and the changes that added it in the DRI tree should be backed out so that nothing else comes to rely on it. Ah, o.k. strtod is o.k. - strtof isn't. When I was tinkering with strtod() a while back I couldn't get it to work correctly/reliably. I suspected a bug in glibc. strtof() seems to be OK though. I'll have to experiment with it a bit more someday. Anyway, _mesa_strtof() isn't really being used yet. -Brian --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] missing xf86strtof definition
On Fri, Feb 07, 2003 at 11:34:41AM -0700, Brian Paul wrote: Alan Hourihane wrote: On Fri, Feb 07, 2003 at 11:26:53AM -0500, David Dawes wrote: On Fri, Feb 07, 2003 at 08:36:27AM -0700, Brian Paul wrote: David Dawes wrote: On Fri, Feb 07, 2003 at 10:55:33AM +1000, Chris Ison wrote: in XFree86 log Symbol xf86strtof from module /usr/X11R6/lib/modules/extensions/libGLcore.a is unresolved! this function doesn't exist in XFree86 trunk, nor DRI trunk (going by grep), how ever it is used in extras/Mesa/src/imports.c did someone forget to commit its definition? strtof isn't very portable (C99), so something else should be used (maybe sscanf, for example). Thanks for the tip - I may make that change. Well, xf86strtof() won't be available in any XFree86 release in the forseeable future, and the changes that added it in the DRI tree should be backed out so that nothing else comes to rely on it. Ah, o.k. strtod is o.k. - strtof isn't. When I was tinkering with strtod() a while back I couldn't get it to work correctly/reliably. I suspected a bug in glibc. strtof() seems to be OK though. I'll have to experiment with it a bit more someday. O.k. Anyway, _mesa_strtof() isn't really being used yet. Yep. I noticed that. I just changed it in the DRI trunk to cancel out the noisy message in the XFree86 log so no-one else complains. Alan. --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
Ian Romanick wrote: CVSROOT: /cvsroot/dri Module name: xc Repository: xc/xc/lib/GL/mesa/src/drv/r200/ Changes by: idr@sc8-pr-cvs1. 03/02/07 12:07:04 Log message: Fix DOT3 texture combine env. Modified files: xc/xc/lib/GL/mesa/src/drv/r200/: r200_texstate.c Revision ChangesPath 1.11 +74 -47xc/xc/lib/GL/mesa/src/drv/r200/r200_texstate.c I don't have a local copy of the mesa-4.0.4 branch. Could somebody commit this change to that tree? It's a pretty easy fix should make Linus happy. :) --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
Ian Romanick wrote: Ian Romanick wrote: CVSROOT:/cvsroot/dri Module name:xc Repository:xc/xc/lib/GL/mesa/src/drv/r200/ Changes by:idr@sc8-pr-cvs1.03/02/07 12:07:04 Log message: Fix DOT3 texture combine env. Modified files: xc/xc/lib/GL/mesa/src/drv/r200/: r200_texstate.c Revision ChangesPath 1.11 +74 -47xc/xc/lib/GL/mesa/src/drv/r200/r200_texstate.c I don't have a local copy of the mesa-4.0.4 branch. Could somebody commit this change to that tree? It's a pretty easy fix should make Linus happy. :) I'll do it. Keith --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
On Fri, 7 Feb 2003, Keith Whitwell wrote:
I don't have a local copy of the mesa-4.0.4 branch. Could somebody
commit this change to that tree? It's a pretty easy fix should make
Linus happy. :)
I'll do it.
Actually, I take that back - I don't have an r200 handy to test the diff
didn't apply cleanly enough to wing it...
Anyone else?
Keith
Here's a hand-merged diff against mesa-4-0-4-branch. How does this look?
--
Leif Delgass
http://www.retinalburn.net
Index: r200_texstate.c
===
RCS file: /cvsroot/dri/xc/xc/lib/GL/mesa/src/drv/r200/r200_texstate.c,v
retrieving revision 1.7
diff -u -r1.7 r200_texstate.c
--- r200_texstate.c 5 Nov 2002 21:19:50 - 1.7
+++ r200_texstate.c 7 Feb 2003 21:41:52 -
@@ -47,6 +47,7 @@
#include mmath.h
#include simple_list.h
#include texformat.h
+#include enums.h
static void r200SetTexImages( r200ContextPtr rmesa,
@@ -702,16 +703,19 @@
{
r200ContextPtr rmesa = R200_CONTEXT(ctx);
const struct gl_texture_unit *texUnit = ctx-Texture.Unit[unit];
+ const struct gl_texture_object *tObj = texUnit-_Current;
+ const GLenum format = tObj-Image[tObj-BaseLevel]-Format;
GLuint color_combine, alpha_combine;
GLuint color_scale = rmesa-hw.pix[unit].cmd[PIX_PP_TXCBLEND2];
GLuint alpha_scale = rmesa-hw.pix[unit].cmd[PIX_PP_TXABLEND2];
if ( R200_DEBUG DEBUG_TEXTURE ) {
- fprintf( stderr, %s( %p, %d )\n, __FUNCTION__, ctx, unit );
+ fprintf( stderr, %s( %p, %d ) format=%s\n, __FUNCTION__,
+ ctx, unit, _mesa_lookup_enum_by_nr( format ) );
}
/* Set the texture environment state. Isn't this nice and clean?
-* The R200 will automagically set the texture alpha to 0xff when
+* The chip will automagically set the texture alpha to 0xff when
* the texture format does not include an alpha component. This
* reduces the amount of special-casing we have to do, alpha-only
* textures being a notable exception.
@@ -729,6 +733,8 @@
const GLenum format = tObj-Image[tObj-BaseLevel]-Format;
GLuint color_arg[3], alpha_arg[3];
GLuint i, numColorArgs = 0, numAlphaArgs = 0;
+ GLuint RGBshift = texUnit-CombineScaleShiftRGB;
+ GLuint Ashift = texUnit-CombineScaleShiftA;
switch ( texUnit-EnvMode ) {
case GL_REPLACE:
@@ -867,6 +873,8 @@
case GL_SUBTRACT:
case GL_DOT3_RGB:
case GL_DOT3_RGBA:
+case GL_DOT3_RGB_EXT:
+case GL_DOT3_RGBA_EXT:
numColorArgs = 2;
break;
case GL_INTERPOLATE:
@@ -880,10 +888,10 @@
case GL_REPLACE:
numAlphaArgs = 1;
break;
-case GL_SUBTRACT:
case GL_MODULATE:
case GL_ADD:
case GL_ADD_SIGNED:
+case GL_SUBTRACT:
numAlphaArgs = 2;
break;
case GL_INTERPOLATE:
@@ -969,14 +977,6 @@
R200_COLOR_ARG( 0, A );
R200_COLOR_ARG( 1, C );
break;
-case GL_SUBTRACT:
- color_combine = (R200_TXC_ARG_B_ZERO |
-R200_TXC_COMP_ARG_B |
-R200_TXC_NEG_ARG_C |
-R200_TXC_OP_MADD);
- R200_COLOR_ARG( 0, A );
- R200_COLOR_ARG( 1, C );
- break;
case GL_ADD_SIGNED:
color_combine = (R200_TXC_ARG_B_ZERO |
R200_TXC_COMP_ARG_B |
@@ -985,16 +985,46 @@
R200_COLOR_ARG( 0, A );
R200_COLOR_ARG( 1, C );
break;
+case GL_SUBTRACT:
+ color_combine = (R200_TXC_ARG_B_ZERO |
+R200_TXC_COMP_ARG_B |
+R200_TXC_NEG_ARG_C |
+R200_TXC_OP_MADD);
+ R200_COLOR_ARG( 0, A );
+ R200_COLOR_ARG( 1, C );
+ break;
case GL_INTERPOLATE:
color_combine = (R200_TXC_OP_LERP);
R200_COLOR_ARG( 0, B );
R200_COLOR_ARG( 1, A );
R200_COLOR_ARG( 2, C );
break;
+
+case GL_DOT3_RGB_EXT:
+case GL_DOT3_RGBA_EXT:
+ RGBshift = 0;
+ Ashift = 0;
+ /* FALLTHROUGH */
+
case GL_DOT3_RGB:
case GL_DOT3_RGBA:
+ /* DOT3 works differently on R200 than on R100. On R100, just
+* setting the DOT3 mode did everything for you. On R200, the
+* driver has to enable the biasing (the -0.5 in the combine
+* equation), and it has add the 4x scale factor. The hardware
+* only supports up to 8x in the post filter, so 2x part of it
+* happens on the inputs going into the combiner.
+*/
+
+ RGBshift++;
+ Ashift = RGBshift;
+
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
Leif Delgass wrote: On Fri, 7 Feb 2003, Keith Whitwell wrote: Actually, I take that back - I don't have an r200 handy to test the diff didn't apply cleanly enough to wing it... Anyone else? Here's a hand-merged diff against mesa-4-0-4-branch. How does this look? Meh. It looks like there's a couple minor issues with it. I guess I'll break down and get yet another branch on my system. :) --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] #others-have-gotten-out-and-so-can-you# mbm
Title: (:**get out today**:) YOU HAVE BEEN **APPROVED** **YOUR- BILL PAYER- REFINANCE HAS BEEN APPROVED** YOUR APPROVED UP TO $50,000.00 PAYOFF EXISTING HIGH INTEREST RATE LOANS REDUCE, CONSOLIDATE, ELIMINATE ALL YOUR BALANCES OUR LOAN OFFICERS ARE WAITING TO HELP YOU NOW ITS EZ AS 1-2-3 GO HERE FOR YOUR LOAN AMOUNT **SUBJECT TO LENDER GUIDLINES** For removal from these mailings please follow this link esxugprqajqp h k n fudq tc czbeqdznuo v spy jefw s
[Dri-devel] Rough-rough-rough draft of texmem-0-0-2 design document
Hello all!
Attached is the initial rough-draft of the design document for the next
generation memory manager. It is currently plain-text. When I polled
people on #dri-devel the consensus was that plain-text would be the most
useful format. I suspect at some point I may change to HTML or
something else that can link within a document. In any case, I have
left in the marks for Jed's (and Emacs') folding mode. My apologies to
all who do not fold. :)
The document is not 100% complete. A few sections, such as the
replacement policy, need more discussion before they can be completed.
I have also included an issues section in the spirit of issues
sections in OpenGL extension documents. I think the most significan
issue is 3.13, but I don't think any of them are trivial. I fully
expect this section to grow. :)
I would *really* like to discuss the document and anything else related
in Monday's #dri-devel meeting. Hopefully people can make it will
have a chance to digest the document by then.
-*- mode: text; mode: fold -*-
DRI Memory Manager texmem-0-0-2 Design
Ian Romanick [EMAIL PROTECTED]
{{{ 1. Introduction
The current texture management system used by the open-source DRI drivers
has reached its limits. The current implementation works, and it does the
functionality that it implements well. However, there is a large class of
functionality that the current system simply cannot easily support.
Additionally, there are a number of cases where the current system is
clearly suboptimal.
The current texture memory manager only supports throw away data. It is
assumed that, with proper synchronization with the rendering hardware, any
data that is in either AGP or on-card memory can be thrown away and
re-loaded at anytime. For texture data loaded from main memory, this
assumption holds true. However, there are several classes of data that need
to be locked for longer than the duration of a single rendering command.
Anytime a texture is a rendering target, be it as the destination of
glCopyTexImage or as the rendering target of a pbuffer, that texture data
cannot be thrown away until after it is copied to some sort of backing
store. This restriction prevents the current memory manager from hardware
accelerating glCopyTexImage. This restriction has also prevented
implementation of pbuffers in open-source drivers and has forced binary-only
driver, such as ATI's FireGL drivers, to use a static, fixed size memory
area for pbuffers.
Significant changes need to be made to the memory management system to
support render-target buffers.
In addition to supporting render-to-texture, pbuffers, and glCopyTexImage,
the DRI should be able to support dynamic allocation of back-buffers and
depth-buffers. While this is a secondary consideration, this will allow
different depth-buffer depths on the same display (i.e., one window can use
a 16-bit depth-buffer while another uses a 24-bit depth-buffer) and
full-screen anti-aliasing (FSAA).
As has recently been discussed on the dri-devel mailing list, texture
uploads in the DRI are not fully pipelined [1]. For applications that need
to use dynamic textures, such as streaming video, this presents a
performance bottleneck. In order to support fully pipelined texture
uploads, a mechanism is needed to determine when rendering using a
particular texture buffer is complete. The current memory manager lacks
such a mechanism.
Each texture image in the DRI can be replicated in memory in as many as
three places. The texture can exist in on-card memory, in backing-store in
main memory, and in storage in the application. As the texture requirements
of games and other applications continues to increase, duplicating texture
data becomes more and more painful. In non-extended OpenGL it should be
possible to reduce the number of copies of a texture to no more than two.
With the use of extensions such as APPLE_client_storage[2] or
ARB_pixel_buffer_object[3], it should be possible to achieve single-copy
textures.
The remainder of this document is divided into two major sections. The
first section details the design of the new memory manager. This section is
further divided into a section detailing the the data structures used in the
implementation and a section detailing division of work between the kernel
driver and the user space driver.
As this is intended to be a living document, the remaining section describes
the open issues addressed during the design process. Issues are marked as
either open or closed. Each issue will have some description of the problem
and possible solutions. Each closed issues will have a description of the
resolution. It is expected the the resolution of closed issues will be
incorporated in the other sections of the document.
}}}
{{{ 2. Design of the memory manager
{{{ 2.1 Data structures
Each of the main data structures used by the memory manager lives in a
shared memory space
[Dri-devel] TIME TO CHANGE CAREERS?
Industry leader seeks entrepreneurs for national and international market expansion. We have an immediate need and are willing to train and develop even non- experienced individuals in local and international markets. Candidates must be self-motivated individuals with the entrepreneurial drive to run their own independent business. Here are some highlights: Huge compensation benefits program offered: Uncapped commissions and bonuses. 5 different ways to make money! Residual income from repeat business. Total Work from Home Flexibility: No commuting necessary! Work from home environment. P/T or F/T. Create your own schedule and hours. No sales experience expected or needed. Company Perks: National/International all expense paid vacations, business or pleasure. Car allowance available. Health Insurance benefits available. Our 12 year-old Inc 500 company has developed proprietary products to help people quickly and easily solve health problems in a multi-billion dollar market place! We offer the best company backing in the industry: Full Company Support: Each independently run business is backed with full company support. No territories to worry about. All orders are processed and shipped by the company. Full Training: Personal one-on-one training by top company leaders. Work with company leaders that are focused on your success. What we expect from you: Strong work ethic required. Honesty and integrity expected. Management / leadership skills helpful, but not necessary. Respond immediately to receive a FREE information pack on these amazing products and how you can MAKE MONEY FROM HOME! Click Here! To be removed from our mailing lists, please click here. 2839uxyC5-795YrKc6946ysTT2-55l27 --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] rates are down BB 4314UvEW4-873gpGG5484Jwwr6-897-28
Title: ::M:: Hi, Wwqyaf OR4s4FMlSp 7981HOHs5-105NnyR6l17N¬HSDMéX¬²'²Þu¼¢êÜxZ+á'µêé®+ Øþ >.)îÅj+Ô¨ëax6I硶Úÿ 0½«(~Üç(:âuëÞf¢)à+-¸z÷¥+-²Ê.Ç¢¸ ëa¶Úlÿùb²Û,¢êÜyú+éÞ·ùb²Û?+-wèýÚâuëÞ
