Re: [Mesa-dev] headers for src/asm_mmx.c
>On Tue, 8 Jun 1999, Holger Waechtler wrote: > >dlopen is really easy to understand: Based on your explanation of uinx dl___() calls and my fairly extensive knowledge of the Windblows counterparts I'd say it would take less than an hour to hack a dlopen() interface on top of the Win32 API calls, keeping all other code in Mesa unknowing of at least *that* difference. At least theoretically. There is the twist that Win32 supports at least three different call sequences (but system DLLs *should* be "declspec(stdcall)"). What's actually going on in the different support DLLs for the 3DHW (Glide2x.DLL, VERITE.DLL, etc.) could vary quite a bit since it's all IHV specific. Just my 2c. -Ted ___ Mesa-dev maillist - [EMAIL PROTECTED] http://lists.mesa3d.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] experimental branch
Keith Whitwell wrote: > > Brian Paul wrote: > > > > Keith, I'd like to hear what your longer-term coding plans are. Do > > you see a milestone in your work for a 3.1 release? > > I think you could say that the latest batch of changes pretty much > represents the end of a certain line of improvements. I know Holger is > doing some 3dnow assembly in support of those changes, and there is > other tweaking possible. Apart from those issues I'm happy to draw a > line under what's been done so far and call it a unit. > > My next change to the Mesa core will probably be to provide some support > for floating point colors if that is what we're getting from the API. > I'm also interested in trying to clean up the way we handle vertex > copying at the end of an immediate vb, opening up the fast path to the > immediate pipeline, and fixing some other immediate mode issues of my > own making. I don't think these changes are worth delaying a release > for. > > So I think I've done my last major chunk of coding for this release - > just clean-up, bugfixes and everybody else's work to go... OK, great. Here's what's left, off the top of my head: - conformance testing (I'll try to get back to this ASAP) - 3Dfx driver bugs? (Joe Water's fog bug, for example) - Windows driver bugs (Wilmot Theierry's list of May 28) - put src-glut/ into CVS - is Windows support still in need of tweaking? - multi-byte font bug in GLX - library naming issue: libMesaGL.so vs libGL.so (probably should switch to the later for 3.1) - should GL_SGIS_multitexture be removed? I say yes. - configure-based building? Wait and see, I think. Any additions? -Brian -- Brian PaulAvid Technology / Softimage [EMAIL PROTECTED] ___ Mesa-dev maillist - [EMAIL PROTECTED] http://lists.mesa3d.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] experimental branch
Stephen J Baker wrote: > Perhaps it's time for Mesa to go to the dual-stream approach of the > Linux Kernel and other packages like The GIMP where odd numbered > releases are where new code goes and even numbered get all the bug > fixes. > ... > What does everyone else think about this idea? I'll have to think about it for a while but my first instinct is to stick with the current system. That is, release a series of betas which initially introduce new optimizations and features and progress toward bug-fix betas. After I've released a beta which gets few or no bug reports I'll typically rename that beta as a final release. I believe there are enough people grabbing the betas to exercise it acceptably. This has worked reasonably well so far. There are always bug fixes for the last official release (ala patches_to_3.0/ on the ftp site) but they're seldom serious or widely experienced by users. I don't relish the thought of fixing bugs in two branches. The time between the 3.0 and 3.1 releases is going to be much longer than normal. That's because there's been a tremendous amount of new work. I'd like to see smaller, more frequent releases after 3.1. -Brian -- Brian PaulAvid Technology / Softimage [EMAIL PROTECTED] ___ Mesa-dev maillist - [EMAIL PROTECTED] http://lists.mesa3d.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] 3dnow and g200
On Tue, 8 Jun 1999, Holger Waechtler wrote: > > > On Mon, 7 Jun 1999 [EMAIL PROTECTED] wrote: > > > On Mon, 7 Jun 1999 14:04:49 -0700, Keith Whitwell wrote: > > > > >Can't we have a prebuilt ./configure in the repository? > > > > This is generally considered to be a Bad Idea, since configure is > > autogenerated code and it's easy to forget to update it before checking > > in changes (and it wastes space). The general model is for the > > cvs developers to install autoconf and friends; configure *is* included > > in any source distributions so others can use that. 'make dist' then > > takes care of keeping it up-to-date. > > > > False. > > A prebuilt script is a good idea... I disagree. We should keep configure.in and Makefile.am in the repository but only deliver configure itself with distributions. IMHO, repositories should contain the ultimate sources for things and nothing else. We don't want some misguided person fixing a configuration problem by editing 'configure' and putting it into the repository, only to have it ignored the next time someone runs autoconf. > ...at this time I can't create it on my > own, since my autoconf > is too old. If your autoconf is too old - and you are a developer - just download the new one - it's free and it won't take but 10 minutes to get it up and running. Steve Baker(817)619-2657 (Vox/Vox-Mail) Raytheon Systems Inc. (817)619-2466 (Fax) Work: [EMAIL PROTECTED] http://www.hti.com Home: [EMAIL PROTECTED] http://web2.airmail.net/sjbaker1 ___ Mesa-dev maillist - [EMAIL PROTECTED] http://lists.mesa3d.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] headers for src/asm_mmx.c
On Tue, 8 Jun 1999, Holger Waechtler wrote: > Who says, that our super driver is not able to load it's subdrivers > dynamically ?? > > (could you explain, how dlopen() is used ?? - works it on non-Unix > platforms (MacOS, Dos, Windows) ?? -- if not, we could put some #ifdef's > around it and link at unsupported platforms all subdrivers in the > library.) dlopen is really easy to understand: /* Grab the C math library - load it from disk NOW! */ void *handle = dlopen ( "libm.so", RTLD_NOW ) ; /* Grab the address of the sqrt() function */ my_sqrt = dlsym ( handle, "sqrt" ) ; /* Call the function */ x = (*my_sqrt)( 4 ) ; /* Dump the library to save memory (optional) when you don't need it anymore. */ dlclose ( handle ) ; ...tada! (There is also a dlerror function) There are similar functions available under Windoze - but not with the same API - so some #ifdef WIN32's are going to be needed. I understand that there are still some Unixen that don't have dlopen/dlsym/dlclose - I don't know what the deal is with MacOS, Amiga and some of the other more obscure platforms. I bet BeOS has dlopen - but I don't know for sure. Steve Baker(817)619-2657 (Vox/Vox-Mail) Raytheon Systems Inc. (817)619-2466 (Fax) Work: [EMAIL PROTECTED] http://www.hti.com Home: [EMAIL PROTECTED] http://web2.airmail.net/sjbaker1 ___ Mesa-dev maillist - [EMAIL PROTECTED] http://lists.mesa3d.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] experimental branch
Stephen J Baker wrote: > > > One SPECIFIC reason to go this way is that it gives people > writing low level drivers a stable (even numbered) platform > to work with. > > What does everyone else think about this idea? OK, but really that's what having a development and stable branch in cvs acheives. Then you can number snapshots from each branch however you like - the odd/even way being one that springs to mind, but then again developers should be using cvs, so you don't need odd numbers... Keith ___ Mesa-dev maillist - [EMAIL PROTECTED] http://lists.mesa3d.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] headers for src/asm_mmx.c
Hi, I just committed a portable assyntax version of gl_mmx_blend_transparency. (src/X86/mmx_blend.S) It's not used at this time, we have to create a hook first - (Keith ??) The commented code in mmx.h is taken from blend.c - it does not works since we habe to do this for every context. The best way would be to create a table with all blend functions which the MMX initialisation function could modify. This would be a similiar way how it is done with the xform functions. In MesaCVS/util I stored a file GAS2assyntax.cc, a converter for gcc-generated assembler files to assyntax. compile with $ g++ GAS2assyntax.cc -o GAS2assyntax usage: $ cc -c -save-temps infile.c $ GAS2assyntax infile.s > outfile.S - Holger ___ Mesa-dev maillist - [EMAIL PROTECTED] http://lists.mesa3d.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] experimental branch
On Tue, 8 Jun 1999, Brian Paul wrote: > > The real question is whether Brian wants the next release version to > > include the new code or not. > > I don't have a date in mind for the next beta release. > > I'd like to keep the mainline code pretty much stable. After Keith > has tested and debugged his code branch with most of the demo/sample > programs, Quake, etc. then merging into the mainline is appropriate. > > In other words, when people download and test the latest CVS snapshot > I'd like them to see forward progress (fewer bugs, better speed) > rather than find newly broken code. > > I was planning on doing more conformance testing/fixing pretty soon. > I'd rather do that with stable, mainline code. > > Keith, I'd like to hear what your longer-term coding plans are. Do > you see a milestone in your work for a 3.1 release? Perhaps it's time for Mesa to go to the dual-stream approach of the Linux Kernel and other packages like The GIMP where odd numbered releases are where new code goes and even numbered get all the bug fixes. In this case, that would mean finding a reasonably usable 3.1 and releasing it as 3.2.0 - with the expectation that we'd have to fix bugs in it to make progressively more stable 3.2.1, 3.2.2, etc. Meanwhile (and pretty much simultaneous with the release of 3.2.0 would come 3.3.0 which would be where all the major new features and fancy new algorithms go. When eventually, 3.3.N is stable enough, it becomese 3.4.0 and again, new features go into the odd numbered release 3.5.0. This would be valuable I think because there are times when bugs appear in 3.0 that it would be nice to fix - without having to suffer the growing pains of 3.1 The obvious downside is that bug fixes have to be applied to two releases at once - but I think that's a reasonable price to pay for the benefits of a progressively more stable current release. That in turn means that you don't have to worry so much about converting the current odd-numbered release into an even numbered one for the sake of fixing bugs. I don't think this approach is a good idea for small projects in their early stages - but for something as large and long-lived as Mesa, I think it's a good idea. One SPECIFIC reason to go this way is that it gives people writing low level drivers a stable (even numbered) platform to work with. What does everyone else think about this idea? Raytheon Systems Inc. (817)619-2466 (Fax) Work: [EMAIL PROTECTED] http://www.hti.com Home: [EMAIL PROTECTED] http://web2.airmail.net/sjbaker1 ___ Mesa-dev maillist - [EMAIL PROTECTED] http://lists.mesa3d.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] headers for src/asm_mmx.c
On Mon, 7 Jun 1999, Thomas Tanner wrote: > > I would be happy, if we could do something similiar with the FX/NV/G200 > > driver - Mesa would become a generic super-driver similiar to the SVGA > > X-Server, which decides at runtime, which hardware driver it will use. > > I think that'd be a very bad idea. > Let's try to avoid monolithic designs and select drivers via configure > options or, even better, make Mesa modular (a nice alliteration :) ! > I could add portable dlopen support to Mesa, if you like. > Who says, that our super driver is not able to load it's subdrivers dynamically ?? (could you explain, how dlopen() is used ?? - works it on non-Unix platforms (MacOS, Dos, Windows) ?? -- if not, we could put some #ifdef's around it and link at unsupported platforms all subdrivers in the library.) - Holger ___ Mesa-dev maillist - [EMAIL PROTECTED] http://lists.mesa3d.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] 3dnow and g200
On Mon, 7 Jun 1999 [EMAIL PROTECTED] wrote: > On Mon, 7 Jun 1999 14:04:49 -0700, Keith Whitwell wrote: > > >Can't we have a prebuilt ./configure in the repository? > > This is generally considered to be a Bad Idea, since configure is > autogenerated code and it's easy to forget to update it before checking > in changes (and it wastes space). The general model is for the > cvs developers to install autoconf and friends; configure *is* included > in any source distributions so others can use that. 'make dist' then > takes care of keeping it up-to-date. > False. A prebuilt script is a good idea, - at this time I can't create it on my own, since my autoconf is too old. It should be no problem to run a script on the CVS-Server at every checkin, which generates a new configure file. The g200 people implemented something like this to forward a mail to their dev-list with the commit-log. I don't know, if everybody is allowed to install this script, possibly Rob or Brian have to do this. - Holger ___ Mesa-dev maillist - [EMAIL PROTECTED] http://lists.mesa3d.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] experimental branch
Brian Paul wrote: > > Keith, I'd like to hear what your longer-term coding plans are. Do > you see a milestone in your work for a 3.1 release? I think you could say that the latest batch of changes pretty much represents the end of a certain line of improvements. I know Holger is doing some 3dnow assembly in support of those changes, and there is other tweaking possible. Apart from those issues I'm happy to draw a line under what's been done so far and call it a unit. My next change to the Mesa core will probably be to provide some support for floating point colors if that is what we're getting from the API. I'm also interested in trying to clean up the way we handle vertex copying at the end of an immediate vb, opening up the fast path to the immediate pipeline, and fixing some other immediate mode issues of my own making. I don't think these changes are worth delaying a release for. So I think I've done my last major chunk of coding for this release - just clean-up, bugfixes and everybody else's work to go... Keith ___ Mesa-dev maillist - [EMAIL PROTECTED] http://lists.mesa3d.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] New dead lock in CVS
Keith Whitwell wrote: > > There is another dead lock on the CVS repository, this time restricted > to the src/FX directory. It's been there at least six hours. > > I've sent a message to Rob Walker, but I don't know who else is capable > of looking at this. I'm waiting for Rob to remove the dead lock in the OpenStep/ directory too. I last mailed him last night. I also asked who else could do this for us. I should ask him for CVS admin priviledge. -Brian -- Brian PaulAvid Technology / Softimage [EMAIL PROTECTED] ___ Mesa-dev maillist - [EMAIL PROTECTED] http://lists.mesa3d.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] experimental branch
Keith Whitwell wrote: > > "C.J. Beyer" wrote: > > > > > Ah, I'd was curious why there'd been no cvs updates in so long! It the > > > experimental-1 branch where development occurs, then? A note about this > > > on the website would be helpful! > > > > Actually, I was under the impression that the experimental branch was > just > > a temporary thing until Mesa-3.1-beta2 was released. Now that beta2 > > has been released the development tree is no longer necessary. > > Keith? > > I defer to Brian on this, but I can vouch that some of the code in there > is pretty raw. A week or so of stabilization is required for my stuff > at least. > > The real question is whether Brian wants the next release version to > include the new code or not. I don't have a date in mind for the next beta release. I'd like to keep the mainline code pretty much stable. After Keith has tested and debugged his code branch with most of the demo/sample programs, Quake, etc. then merging into the mainline is appropriate. In other words, when people download and test the latest CVS snapshot I'd like them to see forward progress (fewer bugs, better speed) rather than find newly broken code. I was planning on doing more conformance testing/fixing pretty soon. I'd rather do that with stable, mainline code. Keith, I'd like to hear what your longer-term coding plans are. Do you see a milestone in your work for a 3.1 release? -Brian -- Brian PaulAvid Technology / Softimage [EMAIL PROTECTED] ___ Mesa-dev maillist - [EMAIL PROTECTED] http://lists.mesa3d.org/mailman/listinfo/mesa-dev
[Mesa-dev] New dead lock in CVS
There is another dead lock on the CVS repository, this time restricted to the src/FX directory. It's been there at least six hours. I've sent a message to Rob Walker, but I don't know who else is capable of looking at this. Keith ___ Mesa-dev maillist - [EMAIL PROTECTED] http://lists.mesa3d.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Testing autoconf
Keith Whitwell wrote: > > Kai Schütz wrote: > > > > Thomas Tanner wrote: > > > Please checkout the experimental-1 branch or download the > > > current snapshot http://picasso.ffii.org/mesa/mesa-exp.tar.gz > branch - I don't know where you are getting the source from. >From http://picasso.ffii.org/mesa/mesa-exp.tar.gz ! I'll better check out from the CVS next time. -- |/ |\ai - Kai Schütz mailto:[EMAIL PROTECTED] Hi, I'm not a signature virus. Why don't you just copy me into your signature? - ___ Mesa-dev maillist - [EMAIL PROTECTED] http://lists.mesa3d.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] experimental branch
"C.J. Beyer" wrote: > > > Ah, I'd was curious why there'd been no cvs updates in so long! It the > > experimental-1 branch where development occurs, then? A note about this > > on the website would be helpful! > > Actually, I was under the impression that the experimental branch was just > a temporary thing until Mesa-3.1-beta2 was released. Now that beta2 > has been released the development tree is no longer necessary. > Keith? I defer to Brian on this, but I can vouch that some of the code in there is pretty raw. A week or so of stabilization is required for my stuff at least. The real question is whether Brian wants the next release version to include the new code or not. Keith ___ Mesa-dev maillist - [EMAIL PROTECTED] http://lists.mesa3d.org/mailman/listinfo/mesa-dev
[Mesa-dev] experimental branch
> Ah, I'd was curious why there'd been no cvs updates in so long! It the > experimental-1 branch where development occurs, then? A note about this > on the website would be helpful! Actually, I was under the impression that the experimental branch was just a temporary thing until Mesa-3.1-beta2 was released. Now that beta2 has been released the development tree is no longer necessary. Keith? C.J. Beyer [EMAIL PROTECTED] http://styx.phy.vanderbilt.edu/~cj/ ___ Mesa-dev maillist - [EMAIL PROTECTED] http://lists.mesa3d.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Testing autoconf
On 07-Jun-99 Kai Schütz wrote: > Ok, I tested the packet: (If got a PentiumPro, Debian 2.1 System) Thanks for your help! > It figured out correctly to enable mmx, asm and 3Dnow. It also enabled -DSVGA > ??? I want X11 ! Yes. It has found SVGAlib on your system. X11 doesn't need any special compiler flags. > And where have the libraries gone ? I finally found them under mysterious > hidden ".libs" paths ?! What is this good for ? Libtool stores them (and temporary files) there. > And how do I compile the demos in the varous directories ? > Do I have to "make" each target on it's own ? No. Just do "make check" after you've compiled the libraries. ># make install > Installed a lot of stuff under /usr/local. Why is the library-version > 2.1.2 ? Isn't this supposed to be version 3.1 ? This is a common misunderstanding. Every platform has it's own versioning scheme and libtool uses the appropriate one. I pass the following information to libtool: # CURRENT:REVISION:AGE -version-info 3:2:1 An excerpt from the libtool documentation: CURRENT The most recent interface number that this library implements. REVISION The implementation number of the CURRENT interface. AGE The difference between the newest and oldest interfaces that this library implements. In other words, the library implements all the interface numbers in the range from number `CURRENT - AGE' to `CURRENT'. If two libraries have identical CURRENT and AGE numbers, then the dynamic linker chooses the library with the greater REVISION number. > I can also test this on linux-alpha and SGI/IRIX, and perhaps on a DEC/Ultrix > machine later... That would be great. But we should fix some known bugs first. Thomas Tanner - email: tanner@(ffii.org|gnu.org|ggi-project.org|gmx.de) web: http://home.pages.de/~tanner GGI/Picasso: http://picasso.ffii.org ___ Mesa-dev maillist - [EMAIL PROTECTED] http://lists.mesa3d.org/mailman/listinfo/mesa-dev
RE: [Mesa-dev] headers for src/asm_mmx.c
On 07-Jun-99 [EMAIL PROTECTED] wrote: > I don't see any autoconf stuff in the experimental-1 branch, but I did a > 'cvs update -rautoconf' And tried that. You need to `cvs checkout -rexperimental-1 .' (fresh checkout) or `cvs update -PAd -rexperimental-1' (update) Note that you always have to use -rexperimental-1 due to a bug in CVS. > ./bootstrap failed: > > automake: configure.in: installing `./install-sh' > error while copying > automake: configure.in: installing `./mkinstalldirs' > error while copying > automake: configure.in: installing `./missing' > error while copying > automake: Makefile.am: installing `./INSTALL' > error while copying That's a bug in automake 1.4. You can ignore the warnings. > BTW, isn't autogen.sh a more standard name for this script? No. It conflicts with the GNU AutoGen utility. > ./configure went fine, and the library built and seems to work. > However, 'make all' seems to be broken in the demo directories. I got > make: Nothing to be done for `all'. > in each of them, but everything built when I tried 'make check' > manually. That's the expected behaviour. By default, no demos are built. "make check" builds them and "make exec" in each demo subdirectory executes them. I'll document this in README.autoconf soon. Thomas Tanner - email: tanner@(ffii.org|gnu.org|ggi-project.org|gmx.de) web: http://home.pages.de/~tanner GGI/Picasso: http://picasso.ffii.org ___ Mesa-dev maillist - [EMAIL PROTECTED] http://lists.mesa3d.org/mailman/listinfo/mesa-dev
