Re: [Mesa-dev] 3Dnow asm broken on the K6-III?
Hi Ralph, could somebody who can reproduce this compile Mesa with -DDEBUG in CFLAGS and export MESA_PROFILE=1 before running a program ? The library will perform now some checks on the transformation functions. Beside this I'd like to see the binutils version used by the C compiler (run gcc -v for one sample file - ). Please send me both outputs. - Holger On Thu, 30 Mar 2000, Ralph Giles wrote: Hello all, We've received several reports lately on the Utah-GLX list about the 3Dnow asm code not working for people with K6-IIIs. It shows up under software fallback, so our guess is that it's a problem in the Mesa code. (that, and I don't think we have any 3Dnow in our drivers--just mmx for texture conversion) ___ Mesa-dev maillist - [EMAIL PROTECTED] http://lists.mesa3d.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Line stipple bug
Hi,
here is the fix. Could you check and commit it, Brian ??
- Holger
*** render_tmp.h.oldThu Mar 16 17:33:44 2000
--- render_tmp.hThu Mar 16 17:51:00 2000
***
*** 88,94
RENDER_LINE( j-1, j );
}
!VB-ctx-StippleCounter = 0;
POSTFIX;
}
--- 88,96
RENDER_LINE( j-1, j );
}
!if (VB-Flag[count] VERT_END)
! VB-ctx-StippleCounter = 0;
!
POSTFIX;
}
***
*** 109,117
if (VB-Flag[count] VERT_END) {
RENDER_LINE( i-1, start );
}
-VB-ctx-StippleCounter = 0;
POSTFIX;
}
--- 111,119
if (VB-Flag[count] VERT_END) {
RENDER_LINE( i-1, start );
+ VB-ctx-StippleCounter = 0;
}
POSTFIX;
}
[Mesa-dev] Assembler problem
Hi Brian, hi everybody, I cleaned up the 3dnow stuff and removed some workarounds. We have now the following problem: the routines gl_3dnow_transform_points3_general_raw gl_3dnow_transform_points4_general_raw gl_3dnow_transform_points3_3d_raw gl_3dnow_transform_points4_3d_raw gl_v16_3dnow_general_xform might be assembled incorrect. I can reproduce this with two binutils packages: GNU assembler version 2.9.1 (i586-pc-linux-gnu), using BFD version 2.9.1 produces ill code. GNU assembler version 2.9.1 (i486-linux), using BFD version 2.9.1.0.25 works right. For those who are interested, a diff of two objdumps (3dnow_xform_raw4.S) is included at the end of this mail. You see some wrong opcodes on the left and the translation on the right. I'm not shure, what to do. I'll try to contact somebody of the binutils maintainers. But since the next Mesa release is not far away, we should think about how we can prevent wrong builds. At least we should add a warning in the doc's (Who really reads documentation ? -- perhaps better on the download www-page ??). Additionally a test for the binutil version in the configure script. Or a test, if the produced object file is correct. A lot code needed for such diagnostics exists already in src/debug_xform.c. Comments ?? Ideas ?? - Holger btw: The new code is about 5% faster than the old on apps with _many_ polygons, Q3 is about 2 fps faster on an Athlon w/ Voodoo3 (Benchmarks performed by Dieter Nuetzel). Because of this I'd like to see it in the 3.2 release. --- (objdump -d for both object files, then diff) 2,3c2,3 3dnow_xform_raw4.o.bfd-2.9.1.0.25: file format elf32-i386 3dnow_xform_raw4.o.bfd-2.9.1.0.25 --- 3dnow_xform_raw4.o.bfd-2.9.1: file format elf32-i386 3dnow_xform_raw4.o.bfd-2.9.1 63c63 5b: 49 decl %ecx --- 5b: 41 incl %ecx 66c66 63: 51 pushl %ecx --- 63: 41 incl %ecx 69c69 6b: 59 popl %ecx --- 6b: 41 incl %ecx 72c72 73: 61 popa --- 73: 41 incl %ecx 75,79c75,78 7b: 69 28 b4 0f 0f imull $0xd00f0fb4,(%eax),%ebp 80: d0 81: 9e sahf 82: 0f 0f (bad) 84: 71 30 jnob6 gl_3dnow_transform_points4_general_raw+0xb6 --- 7b: 41 incl %ecx 7c: 28 b4 0f 0f d0 subb %dh,0xf9ed00f(%edi,%ecx,1) 81: 9e 0f 83: 0f 41 30cmovno (%eax),%esi 81,82c80,81 88: 0f d9 9e 0f 0f psubusw 0x38790f0f(%esi),%mm3 8d: 79 38 --- 88: 0f d9 9e 0f 0f psubusw 0x38410f0f(%esi),%mm3 8d: 41 38 477c476 35b: 49 decl %ecx --- 35b: 41 incl %ecx 485c484 36b: 59 popl %ecx --- 36b: 41 incl %ecx 488c487 373: 61 popa --- 373: 41 incl %ecx ___ Mesa-dev maillist - [EMAIL PROTECTED] http://lists.mesa3d.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] OPENGL/MESA
Hi everybody, has anybody of you build Mesa with Visual C for glide ? And compared this with 3dfx' OpenGL driver ? - Holger On Thu, 27 Jan 2000, ralf willenbacher wrote: Stephen J Baker wrote: Also, unless you say *which* other OpenGL and on which platform, (and for which specific resolutions) there is zero information content. dont forget the compiler issue.. gcc and friends are made for portability visual c/c++ 5.0 is only made for wintel and it spills out very optimized assembler code.. its ~15% faster.. maybe ? someone can test this ? is it testable ? :) -- ralf willenbacher ([EMAIL PROTECTED]) ___ Mesa-dev maillist - [EMAIL PROTECTED] http://lists.mesa3d.org/mailman/listinfo/mesa-dev ___ Mesa-dev maillist - [EMAIL PROTECTED] http://lists.mesa3d.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] configure: dec/alpha flags
Hi Brian, I believe, you have to change configure.in. Take this as example, how an alpha might be detected (what $host has a alpha ??): dnl x86 assembler case "$host" in i*86-*-*) have_x86=on ;; *) have_x86=off ;; esac If the problem is related not to the processor, but to the compiler, a something like `cc -v | grep "DEC"` or something like this could help. - Holger On Fri, 17 Dec 1999, Brian Paul wrote: Someone reported a compiler flag problem using the GNU configure build method. The flag -ieee_with_no_inexact must be used when compiling for the Alpha processor using the DEC compiler. Otherwise there's a problem with FP exceptions. The old-style Mesa makefiles did this but I'm not sure how to modify the config.sub or config.guess files to do the same. Can anyone help? -Brian ___ Mesa-dev maillist - [EMAIL PROTECTED] http://lists.mesa3d.org/mailman/listinfo/mesa-dev ___ Mesa-dev maillist - [EMAIL PROTECTED] http://lists.mesa3d.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] autoconf stuff
On Fri, 17 Sep 1999, Brian Paul wrote: Thomas Tanner wrote: I suggest to move all demos to a subdirectory "demos": demos - demos/demos 3Dfx/demos - demos/3Dfx BeOS - demos/BeOS book - demos/book ggi/demos - demos/ggi images- demos/images mtdemos - demos/mthread samples - demos/samples utils - demos/utils xdemos- demos/x11 That would be the only way to support the two separate packages with autoconf. Really?! It shouldn't be hard to detect the presence of those subdirs and conditionally build their contents. But then again, I don't know much about autoconf. We could modify the release-configure-script to call another script, which removes the demo directories from the SUBDIR variable in Makefile.in, if these are not present. Another way (I think, it will be the harder one - ) could be to do this in the toplevel Makefile. However, I recommend the first way. - Holger ___ Mesa-dev maillist - [EMAIL PROTECTED] http://lists.mesa3d.org/mailman/listinfo/mesa-dev
RE: [Mesa-dev] autoconf stuff
On Fri, 17 Sep 1999, Thomas Tanner wrote: On 15-Sep-99 Holger Waechtler wrote: the fixam script, which enables automatic dependency tracking, if gcc and gnu make are available, is now called automatically from bootstrap. No, the other way round: fixam disables automatic dependency tracking, if gcc and gnu make are not available. I decided not to call it from bootstrap because a non-GNU developer you would always overwrite the default Makefile.am's (AUTOMAKE_OPTIONS commented out) when doing CVS checkins. Could you please undo your change? If I understood your script right, it works in both directions, doesn't it ? (I could not test it, since I have no none-gnu compiler - Brian ??) If so, it would be no problem, if people check in 'corrupted' Makefile.am's. Btw: Brian, we must make sure that automatic dependency tracking is disabled before we release beta 3. Otherwise configure won't work on non-GNU systems. That shouldn't be a problem -- in the release the dependent files shouldn't change anymore. - Holger ___ Mesa-dev maillist - [EMAIL PROTECTED] http://lists.mesa3d.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] autoconf stuff
Hi Brian, I removed the automatic fixam call in bootstrap. And I fixed fixam to work in both directions (I was wrong -- it couldn't do the job right; hope it will now - ). - Holger ___ Mesa-dev maillist - [EMAIL PROTECTED] http://lists.mesa3d.org/mailman/listinfo/mesa-dev
[Mesa-dev] FX driver bug
Hi everybody, I tried some of the demos last days both with the X and the FX driver. Some bugs seem to be there: the book/anti.c demo is incredibly coloured and the transparent help screen in the 3dfx/demos/tunnel.c demo is not transparent. The X driver draws both correct. - Holger ___ Mesa-dev maillist - [EMAIL PROTECTED] http://lists.mesa3d.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Fwd: Dev reqd for Mesa3D optimizations
Hi everybody, in my opineon it´s a real hard task to reach about 10 % speedup in Q3, since most functions, which are easy to optimize with the 3dnow or SSE instructions don´t need more then 10% or 12% of cpu time. And there is another problem. Even if the results Josh posted look very impressing (we get speedups up to 6), these are more theoretical. In the benchmark all vertices reside in the L1 cache and so the mov´s are quite fast. In the reality most functions are only about 1.5 or 2 times faster then the C functions because of cache misses. Since the SSE instructions process 4 floats at once, most specialized transforms in xform_tmp.h will be impossible (or really hard) to code. I believe, a better idea would be to introduce fastpaths with big loops, which transform clip a vertex in one function, so that we can´t get cache misses. That´s the way Keith was going with the fxfastpath. I work at a big-loop-3dnow routine, but still need some time (I´ll be out of town next weeks). Perhaps it is possible to introduce something similiar for other cards, perhaps for software rendering, too (Keith ??) In this full_setup function we transform the vertex with a 4x4 matrix, so that the SSE instructions make sense. The cliptest could be done well with them (with some little acrobatics), too. - Holger ___ Mesa-dev maillist - [EMAIL PROTECTED] http://lists.mesa3d.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Makefile.X11 fx_3dnow_fastpath fix
On Sat, 31 Jul 1999, Andree Borrmann wrote: Here is a patch for the linux-3dnow-glide target for the "old" makefiles Andree thanks. I checked it checked in. - Holger ___ Mesa-dev maillist - [EMAIL PROTECTED] http://lists.mesa3d.org/mailman/listinfo/mesa-dev
[Mesa-dev] RE: Let's talk about compiler flags
On Wed, 23 Jun 1999, Thomas Tanner wrote: Should the final release generate a stripped library, which is smaller ? Yes, but automake 1.4 doesn't support it, only the latest CVS snapshots of automake and libtool do :-( Is there a problem to run strip libMesaGL*.so* in the release target of the Makefiles ?? Thomas, could you create a README or INSTALL file, which describes all switches and a 'how to install Mesa, if ./configure fails' ?? Yes, I'm working on it. Great. What do you mean with 'if configure fails'? That should never happen! should. but are you _really_ shure ?? - Holger ___ Mesa-dev maillist - [EMAIL PROTECTED] http://lists.mesa3d.org/mailman/listinfo/mesa-dev
RE: [Mesa-dev] 3dnow code is now in assyntax, in the mainstream
Hi Thomas, please include the x86 assembler only, if you are shure, that binutils support the cpuid command (or you could compile common_x86asm.S). Otherwise the compilation can fail. - Holger ___ Mesa-dev maillist - [EMAIL PROTECTED] http://lists.mesa3d.org/mailman/listinfo/mesa-dev
RE: [Mesa-dev] 3dnow code is now in assyntax, in the mainstream
On Fri, 11 Jun 1999, Thomas Tanner wrote: It doesn't detect my MMX capable Celeron. Did you specified -DUSE_MMX_ASM ?? Yes, but the latest experimental branch seems to detect it. Fine. Then should the mainstream branch do it, too. - Holger ___ Mesa-dev maillist - [EMAIL PROTECTED] http://lists.mesa3d.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] RE: autoconf stuff
On Thu, 10 Jun 1999, Thomas Tanner wrote: On 09-Jun-99 Holger Waechtler wrote: you should not try to compile the ggi stuff, if no ggi was found. That's what the autoconf script actually does. Unfortunately some of Jon's GGI fixes broke it yesterday :( but it's fixed now. A switch --disable-ggi would be nice, even if a ggi library was detected (since ggi is not yet really ready, there might be some broken versions out there). You can disable it using --without-ggi --without-ggi does not works on my computer, since ggi is broken I cant't compile without some hacks in the generated Makefiles. This would probably take too much time. Please use --without-glide instead. (and --without-svga for SVGAlib, --without-x doesn't make sense since Mesa depends on X11 (so far...)) Why do you check for gethostbyname and other networking stuff ?? That's necessary for X11 (it's part of the X11 checks). Wouldn't it be enough to check for those things, which require Modifications in the Makefiles ?? - 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] 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] 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
[Mesa-dev] headers for src/asm_mmx.c
Hi Ralph, The asm_???.c /.h /.S files are not used at this time. Take a look into the files in src/X86 instead (prefer the experimental-1 CVS branch, there are the 3Dnow related things in this folder, too). It should work once like this: For a x86 target, cmopile with -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM. Your configure script has to test (perhaps by compiling one of the x86/MMX/3dnow files), if the binutils know all necessairy commands. If not, you should not define the relating USE_XXX_ASM. If you compiled them all into the library, void gl_init_all_x86_asm (void) tests, which additional capabilities the cpu supports and hooks in the right code. Please contact also Thomas Tanner, who is trying to write autoconf support for Mesa. - Holger ___ 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, Keith Whitwell wrote: I think a better approach would be to compile everything we are capable of do the checks at runtime. That's exactly the thing I want to do. The linux-3dnow target is currently the one which compiles in all available optimisations and decides at startup, which ones it will use. This is done by gl_identify_cpu_features. To be shure, that the feature-detection-function works correct, it gives out some messages at this time. As soon it is well tested, we can remove all related printf's. Later we can rename the linux-3dnow(-glide) to linux-generic-x86 or something like this. (And if the autoconf stuff works, we won't need these targets anymore - ) 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. Hmmm..., what interface use the GLX-drivers -- could we use them for a Mesa-without-glx, too ??? But back to the x86/MMX/3dnow stuff: the configure script could use a logic like this: try to compile common_x86asm.S -- sucess ?? yes - cpuid command is supported by binutils, good. try to compile x86a.S -- success ?? yes - define USE_X86_ASM add all x86*.S files to the list of files to compile try to compile a MMX file -- (there exists none at this time) try to compile a 3dnow_* file -- success ? yes - binutils know 3dnow commands, define USE_3DNOW_ASM add all 3dnow files to the list of files to compile - Holger ___ Mesa-dev maillist - [EMAIL PROTECTED] http://lists.mesa3d.org/mailman/listinfo/mesa-dev
[Mesa-dev] 3dnow code in assyntax-style
Hi everybody,
I just committed a new version of the 3dnow xforms to the experimental-1
branch. Everything is now in Josh's portable assyntax-style. I moved all
related files to src/X86.
common_x86asm.h /.S contains a new cpu detection routine, it tests
original Intel cpu's, generic MMX processors and 3Dnow capable AMD cpu's.
Please test it on every computer you can reach; as soon I can be shure
that it works correct, I'll remove the printf('XXX cpu detected.');
The 3Dnow asm should compile now without GAS, too. (Keith H. ??)
It all needs still some cleanup, I hope next week I'm ready.
A lot of fun -
- Holger
btw: I don't know why, but the current experimental-1 branch Makefiles
need glide.h even you compile only linux-3dnow or linux-386.
___
Mesa-dev maillist - [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Re: newest 3DNow! code
If test_all_transform_functions() is used in a few different files, maybe it would be better to move it to a .c file instead of having a separate instance for each use? you are right. Have a look on my new version with included benchmark macros. Note that they will only work on 586 CPU's or higher (they use thr rdtsc command to count cycles). The way the macros are activated is not pretty good this time, any idea how we could make shure that they are only included on Pentium class CPU's ?? Do you change it to .c file or shall I do ? Holger ___ Mesa-dev maillist - [EMAIL PROTECTED] http://lists.mesa3d.org/mailman/listinfo/mesa-dev
