[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ëÞ
[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] 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
[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
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
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++; +
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
Keith Whitwell wrote: 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 -47 xc/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. 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 --- 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
[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] 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
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: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
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. 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
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
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
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
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] 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] 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] 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
[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
[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
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] 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] 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. cut&paste 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
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
[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: >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
[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