Re: [Dri-devel] Tribes 2 Lockups: Help me pinpoint the problem...
Marc Poulhiès wrote: I know that closed source drivers from ati are not discussed here, but with my radeon 8500 and tribes2 i have exactly the same probleme. Maybe this is a probleme from tribes2 and not the dri :) Maybe. But it _used_ to work fine under xfree86 4.1.0 4.2.0. Has anyone had any success with Tribes 2 and the Radeon TCL drivers? --- This sf.net email is sponsored by:ThinkGeek Gadgets, caffeine, t-shirts, fun stuff. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] My experiance with DRI and gcc-3.0(.4)
The install.sh, included with the snapshots,(and make -f Makefile.linux) has allays built modules that insmod fine, even print every thing and rmmod, but they don't let X setunique. getunique worked fine. The error I get from an strace is no access, when calling the setunique ioctl. If I build the kernel using make-kpkg(that really only calles make modules) every thing works fine, I have to mv Makefile.kernel Makefile and I rm Imakefile Makefile.linux. When running make -f Makefile.linux it has $(cc) that runes cc, a link to gcc(V2.95.4). When running make-kpkg I'm using the New and Improved(it's been broken, and re-fixed) gcc-3.0(V3.0.4) so I put a line CC = gcc-3.0 in my Makefile.linux (added -O3 -march=athlon, removed -g) and made radeon.o, and it works. If you want I can add some features to install.sh, command line params for all options -y for no questions ect. At present I can export CC, but I'l tweak my Makefile.sh from now on. Also make World will crash if I try to use gcc 3.0. __ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com --- This sf.net email is sponsored by:ThinkGeek Gadgets, caffeine, t-shirts, fun stuff. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Tribes 2 Lockups: Help me pinpoint the problem...
Bonjour Daniel! Fri, 12 Jul 2002 11:03:31 +1000, tu as dit : Marc Poulhiès wrote: I know that closed source drivers from ati are not discussed here, but with my radeon 8500 and tribes2 i have exactly the same probleme. Maybe this is a probleme from tribes2 and not the dri :) Maybe. But it _used_ to work fine under xfree86 4.1.0 4.2.0. Has anyone had any success with Tribes 2 and the Radeon TCL drivers? I wish i could test with tcl enabled, but i dont know why, glxinfo gives me that: -unknown chip id, assuming full r200 support -disabling TCL support I have an ATI Radeon 8500 QL (if it can help) I must say i'm impressed by the performance of these drivers, as i get the same fps with ati closed source ones. --- This sf.net email is sponsored by:ThinkGeek Gadgets, caffeine, t-shirts, fun stuff. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] My experiance with DRI and gcc-3.0(.4)
On Thu, Jul 11, 2002 at 11:58:56PM -0700, Mike Mestnik wrote: The install.sh, included with the snapshots,(and make -f Makefile.linux) has allays built modules that insmod fine, even print every thing and rmmod, but they don't let X setunique. getunique worked fine. The error I get from an strace is no access, when calling the setunique ioctl. If I build the kernel using make-kpkg(that really only calles make modules) every thing works fine, I have to mv Makefile.kernel Makefile and I rm Imakefile Makefile.linux. Could this be your distribution applies some patch? When running make -f Makefile.linux it has $(cc) that runes cc, a link to gcc(V2.95.4). When running make-kpkg I'm using the New and Improved(it's been broken, and re-fixed) gcc-3.0(V3.0.4) so I put a line CC = gcc-3.0 in my Makefile.linux (added -O3 -march=athlon, removed -g) and made radeon.o, and it works. So, if I understood correctly, you need some way to control which gcc is used on the module compilation. If you want I can add some features to install.sh, command line params for all options -y for no questions ect. At present I can export CC, but I'l tweak my Makefile.sh from now on. That would be really great! Especially if with a --help option. Also make World will crash if I try to use gcc 3.0. Although I haven't done again after the bsd-branch merge I already compiled the mach64 branch with gcc-3.1 without problems. One can get into problems if one compiles modules with a different versions than the rest. José Fonseca --- This sf.net email is sponsored by:ThinkGeek Gadgets, caffeine, t-shirts, fun stuff. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] My experiance with DRI and gcc-3.0(.4)
hi, as you are talking about install.sh, i find a little problem when using it for the first time. When you dont have a kernel module installed before the first run of install.sh, the modprobe fails...a simple depmod -a then the modprobe fixes this... I was thinking that maybe this depmod -a should be included in the script. Is this a bad idea? --- This sf.net email is sponsored by:ThinkGeek Gadgets, caffeine, t-shirts, fun stuff. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] My experiance with DRI and gcc-3.0(.4)
On Fri, Jul 12, 2002 at 11:21:29AM +0200, Marc Poulhiès wrote: hi, as you are talking about install.sh, i find a little problem when using it for the first time. When you dont have a kernel module installed before the first run of install.sh, the modprobe fails...a simple depmod -a then the modprobe fixes this... I was thinking that maybe this depmod -a should be included in the script. Is this a bad idea? No, it's a good idea alright, and I've just add '/sbin/depmod -a' to the install.sh script after installing/restoring the kernel modules. The next snapshots will have it. José Fonseca --- This sf.net email is sponsored by:ThinkGeek Gadgets, caffeine, t-shirts, fun stuff. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64: multi texture crash with after last update
On Fri, Jul 12, 2002 at 04:28:25AM +0200, Felix Kühling wrote: Hi, just updated after reading José's mail about the MACH64_NATIVE_VTXMFT and tried running some apps. q3demo and quake2 crashed with multi textures enabled: q3demo.x86: mach64_tris.c:518: mach64_draw_triangle: Assertion `vb == vbchk' failed. I found the problem in the COPY_VERTEX macro. The movsl instruction doesn't decrement %ecx when there is no rep prefix, so you have to decrease afterwards. Here's the fix: [...] It's now on CVS. I though that the %ecx decrement was already handled by the 'movsl' instruction and that the 'rep' prefix just added the conditional jump... Thanks. José Fonseca --- This sf.net email is sponsored by:ThinkGeek Gadgets, caffeine, t-shirts, fun stuff. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] No Cost Out Of Pocket: REFI 4509BXja0-449lMZr6154vTE-23
Warning Unable to process data: multipart/mixed;boundary==_NextPart_000_00D4_30C83A7B.C5605D52
Re: [Dri-devel] good buy?
Ian Molton wrote: Is the Hercules 3D Prophet 8500 a good card? (is the 2D stable at 1600x1200, unlike my 7500 VIVO which has a noticeable 'noise' so that vertical lines arent smooth, but somewhat rough looking) i think it's a fairly decent one. but there are rumors that some hercules 8500 cards on the market only have one ramdac (i.e. no possibility for dual-head), so I'd double-check that before buying Also keep in mind that the Hercules 8500 is only clocked at 240MHz memory clock, some others have 250MHz. unfortunately there's such a load of 8500 OEM boards, it's a bit hard not to get confused... I've got a FIC card (8500LE), which seems to be 100% identical with the original ati-boards (no traces of FIC in the bios-strings, ati-logos on the board, covered with fic-stickers, etc.). I take that as a plus, because that way chances are best to get maximum compatibility with the retail cards. Mine was even the cheapest on the market that time i bought it, so maybe lookout, if you can find this model somewhere will it work 2D on a stock X 4.2 ? yes what framerate does the beta DRI accel for it give in Quake3 ? i only tested on a selfmade demo (not an official one), but the relative numbers should give you an idea nevertheless: win98: ~150-160 fps X, firegl drivers: ~130 fps X, r200-branch: ~80 fps keep in mind that the r200 branch is very new, so there's surely room for improving the performance on my system, however, q3a will usually crash after some minutes of playing, other people have reported that it runs stable, so your mileage may vary All questions I must know answers to ;) Might have a chance to upgrade soon! (like, tomorrow, so answer me quick please :-) --- This sf.net email is sponsored by:ThinkGeek Gadgets, caffeine, t-shirts, fun stuff. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] SSE on Athlons (and FreeBSD)
On Thu, Jul 11, 2002 at 02:46:24AM -0600, Eric Anholt wrote:
A while ago I added the stuff to the config/cf/* to enable USE_SSE_ASM
on FreeBSD, but today found that it wasn't enabled on my athlon. I
added the proper sysctl check for it, but it still wasn't enabled. It
turns out the Athlon's extended CPUID function has most of the same
feature bits as the standard CPUID features function, but it doesn't
ever enable the SSE bit. I've made a patch that ORs in the bit from the
standard function, enabling SSE on new Athlons. It's attached.
A better fix would be to actually enable SSE before FreeBSD does its
feature flag detection. Linux does the following very early on..
/* Bit 15 of Athlon specific MSR 15, needs to be 0
* to enable SSE on Palomino/Morgan CPU's.
* If the BIOS didn't enable it already, enable it
* here.
*/
if (c-x86_model == 6 || c-x86_model == 7) {
if (!cpu_has(c, X86_FEATURE_XMM)) {
printk(KERN_INFO Enabling disabled K7/SSE Support.\n);
rdmsr(MSR_K7_HWCR, l, h);
l = ~0x8000;
wrmsr(MSR_K7_HWCR, l, h);
set_bit(X86_FEATURE_XMM, c-x86_capability);
}
}
Seems some BIOSen didn't enable this magical bit. Your patch is just
doing the FreeBSD equivalent of the set_bit() call above, which is
fine for anything that parses those flags, but breaks any userspace
that does its own cpuid() calls to find out cpu capabilities.
Dave
--
| Dave Jones.http://www.codemonkey.org.uk
| SuSE Labs
---
This sf.net email is sponsored by:ThinkGeek
Gadgets, caffeine, t-shirts, fun stuff.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon scratch register writeback patch
Looks good, but I think I've got an even better patch: http://www.penguinppc.org/~daenzer/DRI/radeon-nommio.diff I've moved the initialization and put the scratch registers right behind the ring read pointer, this should work with PCI GART and all kinds of AGP GART. I'll commit this now. This looks ok. The one thing I'd say is that we've added functionality to the kernel module, so we should bump the minor version number (ie 1.4.0) -- this means that you can test rmesa-drm.minor (or whatever) instead of firing off the ioctl checking for EINVAL. Keith --- This sf.net email is sponsored by:ThinkGeek Gadgets, caffeine, t-shirts, fun stuff. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] R200 video signal lost
Michal Kozlowski wrote: On Thu, 11 Jul 2002, Stefan Lange wrote: compiling from cvs shouldn't be a problem, I just followed the DRI Compilation Guide from the website and everything went fine (you might have to compile the kernel drm-module manually, but that's no trouble) Completed the compile didn't help me any still does that same thing, did you find that you had to remove some misplaced and from some files? If you've got those in your files it means CVS has somehow gotten confused. If you do something like a 'cvs update' from the top level directory, you should get *NO* lines that look like: M xc/asdf/adsf/adsf/somefile.c Note the capital 'M'. I bet you have a few. Remove them update again. Keith --- This sf.net email is sponsored by:ThinkGeek Gadgets, caffeine, t-shirts, fun stuff. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] infinite loop in xc/xc/extras/Mesa/src/tnl/t_vb_render.c
Michael Schlueter wrote: Hi, I'm trapped in an infinite loop in xc/xc/extras/Mesa/src/tnl/t_vb_render.c :) Ok, I was debugging a program with ddd that crashes sometimes but this time it took the hole cpu time so I broke it up and did a look where it was (see above). I did a few steps to get an impression what is happen there and was astonished that it was in a loop where it couldn't get out (run_render() there is a for loop, i and length where both 0). Does anybody knows how I can get out there or does I have to stay there forever? I don't know the issure how this could happen but if anybody is interested in any state of another variable I won't touch ddd for the next three hours and send it to him. Michael, I'm sure the 3 hours is up now... This is a bug in the Mesa tnl code, so it's important to try track it down. What program is giving this behaviour? How did you get it to do this? Can you post a demo that does the same thing? Keith --- This sf.net email is sponsored by:ThinkGeek Gadgets, caffeine, t-shirts, fun stuff. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] R200 video signal lost
Michal Kozlowski wrote: Hi everyone, Thanks to the help of Stefan and others I got my r200 to work, from Stefans lspci logs I was able to figure out why I lost my signal, it was hardware configuration related. I had to disable Fast Writes for AGP, simple solution took a bit of time to find, but anyone else having problems make sure to check that :o) Hmm, This should be an FAQ. I'll put it in the README.r200 file at least. Keith --- This sf.net email is sponsored by:ThinkGeek Gadgets, caffeine, t-shirts, fun stuff. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Tribes 2 Lockups: Help me pinpoint the problem...
Marc Poulhiès wrote: Bonjour Daniel! Fri, 12 Jul 2002 11:03:31 +1000, tu as dit : Marc Poulhiès wrote: I know that closed source drivers from ati are not discussed here, but with my radeon 8500 and tribes2 i have exactly the same probleme. Maybe this is a probleme from tribes2 and not the dri :) Maybe. But it _used_ to work fine under xfree86 4.1.0 4.2.0. Has anyone had any success with Tribes 2 and the Radeon TCL drivers? I wish i could test with tcl enabled, but i dont know why, glxinfo gives me that: -unknown chip id, assuming full r200 support -disabling TCL support I have an ATI Radeon 8500 QL (if it can help) I must say i'm impressed by the performance of these drivers, as i get the same fps with ati closed source ones. TCL support hasn't been written yet. What's there is the leftover radon 7xxx code, so I just disable it. It's being worked on now. Keith --- This sf.net email is sponsored by:ThinkGeek Gadgets, caffeine, t-shirts, fun stuff. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] NURBs + Autonormal peculiarity
Andy Isaacson wrote: On Thu, Jul 11, 2002 at 06:10:01PM -0400, Mike Westall wrote: The attached program illustrates a shading anomaly we have encountered while attempting to use autonormal in conjunction with nurbs. The shading of the sphere is seriously screwed up while running with indirect rendering on the standard X server packaged with RH 7.3. It can be fixed by uncommenting the /* #define CORRECT 1 */ on line 8. Your example did fail for me on RH7.1 as well -- the sphere was rendered in 4 quarters of solid shading, but a recent DRI build rendered it just fine. I'll take a screen shot when I'm back at work tomorrow... Oddly enough the EXACT problem that occurs with unaccelerated rendering on XFree86 also occurs with the OpenGL version that comes with recent Sun Solaris boxes. Thus we may well have a bug that is simply latent on SGI | NV. I ran the test on a Solaris 8 system with the OpenGL ogl123_rt32_64 downloaded from Sun's OpenGL for Solaris website (Ultra 10 with Elite3D graphics) and it rendered correctly. I expect that this is either an issue in the GLU nurbs code or in Mesa's evaluator code. The SGI SI GLU library has better NURBS support that Mesa's original GLU library. Make sure you're using the former (identified as version 1.3 with the GLU_EXT_nurbs_tessellator, GLU_EXT_object_space_tess extensions by glxinfo). Typically, if you construct a sphere out of Bezier patches two of the corners get collapsed into one point at +/- 1 on the X,Y or Z axis. When this happens, computing the partial derivatives of the surface breaks down, thus producing bad normals. There are work-arounds for this but it can be tricky. -Brian --- This sf.net email is sponsored by:ThinkGeek Gadgets, caffeine, t-shirts, fun stuff. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] NURBs + Autonormal peculiarity
On Fri, Jul 12, 2002 at 07:54:11AM -0600, Brian Paul wrote: Andy Isaacson wrote: On Thu, Jul 11, 2002 at 06:10:01PM -0400, Mike Westall wrote: The attached program illustrates a shading anomaly we have encountered while attempting to use autonormal in conjunction with nurbs. The shading of the sphere is seriously screwed up while running with indirect rendering on the standard X server packaged with RH 7.3. It can be fixed by uncommenting the /* #define CORRECT 1 */ on line 8. Your example did fail for me on RH7.1 as well -- the sphere was rendered in 4 quarters of solid shading, but a recent DRI build rendered it just fine. I'll take a screen shot when I'm back at work tomorrow... I've put a screenshot of the misrendered sphere at http://web.hexapodia.org/~adi/nurbsphere.png I got that result on a fairly standard RedHat 7.1 system, but I can't tell if it's using Mesa (client-side rendering) or indirect-software rendering. % ldd ./a.out|head -5 libGLU.so.1 = /usr/lib/libGLU.so.1 (0x40024000) libGL.so.1 = /usr/lib/libGL.so.1 (0x40038000) libm.so.6 = /lib/i686/libm.so.6 (0x4029a000) libc.so.6 = /lib/i686/libc.so.6 (0x402be000) libX11.so.6 = /usr/X11R6/lib/libX11.so.6 (0x403ee000) % ls -l /usr/lib/libGL*.so lrwxrwxrwx1 root root 19 Sep 10 2001 /usr/lib/libGL.so - libGL.so.1.2.030401* lrwxrwxrwx1 root root 20 Sep 10 2001 /usr/lib/libGLU.so - libGLU.so.1.1.030401* % rpm -qf /usr/lib/libGL.so Mesa-devel-3.4-13 % rpm -qa|grep Mesa Mesa-3.4-13 Mesa-devel-3.4-13 % glxinfo display: :0.0 screen:0 direct rendering: No server glx vendor string: SGI server glx version string: 1.2 server glx extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context client glx vendor string: SGI client glx version string: 1.2 client glx extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context, GLX_ARB_get_proc_address GLX extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context OpenGL vendor string: VA Linux Systems, Inc. OpenGL renderer string: Mesa GLX Indirect OpenGL version string: 1.2 Mesa 3.4 [...] -andy --- This sf.net email is sponsored by:ThinkGeek Gadgets, caffeine, t-shirts, fun stuff. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] NURBs + Autonormal peculiarity
Andy Isaacson wrote: On Fri, Jul 12, 2002 at 07:54:11AM -0600, Brian Paul wrote: Andy Isaacson wrote: On Thu, Jul 11, 2002 at 06:10:01PM -0400, Mike Westall wrote: The attached program illustrates a shading anomaly we have encountered while attempting to use autonormal in conjunction with nurbs. The shading of the sphere is seriously screwed up while running with indirect rendering on the standard X server packaged with RH 7.3. It can be fixed by uncommenting the /* #define CORRECT 1 */ on line 8. Your example did fail for me on RH7.1 as well -- the sphere was rendered in 4 quarters of solid shading, but a recent DRI build rendered it just fine. I'll take a screen shot when I'm back at work tomorrow... I've put a screenshot of the misrendered sphere at http://web.hexapodia.org/~adi/nurbsphere.png I got that result on a fairly standard RedHat 7.1 system, but I can't tell if it's using Mesa (client-side rendering) or indirect-software rendering. % ldd ./a.out|head -5 libGLU.so.1 = /usr/lib/libGLU.so.1 (0x40024000) libGL.so.1 = /usr/lib/libGL.so.1 (0x40038000) libm.so.6 = /lib/i686/libm.so.6 (0x4029a000) libc.so.6 = /lib/i686/libc.so.6 (0x402be000) libX11.so.6 = /usr/X11R6/lib/libX11.so.6 (0x403ee000) % ls -l /usr/lib/libGL*.so lrwxrwxrwx1 root root 19 Sep 10 2001 /usr/lib/libGL.so - libGL.so.1.2.030401* lrwxrwxrwx1 root root 20 Sep 10 2001 /usr/lib/libGLU.so - libGLU.so.1.1.030401* Looks like GLU 1.1 (the old Mesa version). SGI's GLU 1.3 is what you want. It's been included with the normal Mesa distro for quite a while now. If you download Mesa 4.0.3 you can build a new libGLU.so.1.3 and replace your old one. -Brian --- This sf.net email is sponsored by:ThinkGeek Gadgets, caffeine, t-shirts, fun stuff. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] NURBs + Autonormal peculiarity
I have just rerun the nurb program on another machine which is running the distribution version of XFree86 4.2.0 which I downloaded as source and built on May 20, 2002. Accelerated rendering is on and working through an r128. This version appears to build libGLU 1.3 along with Mesa 3.4.2. The problem also persists there. So I think that the libGLU version is not the key -- but that probably Mesa 4.x may well contain the solution. Thanks for the help, Mike === Application Info == projects/glut-1.0 == ldd ./nurb4 | head -10 libGL.so.1 = /usr/lib/libGL.so.1 (0x40029000) libGLU.so.1 = /usr/X11R6/lib/libGLU.so.1 (0x401fd000) libglut.so.3 = /usr/lib/libglut.so.3 (0x4027) libm.so.6 = /lib/i686/libm.so.6 (0x402a2000) libXmu.so.6 = /usr/X11R6/lib/libXmu.so.6 (0x402c5000) libX11.so.6 = /usr/X11R6/lib/libX11.so.6 (0x402da000) libpthread.so.0 = /lib/i686/libpthread.so.0 (0x40392000) libc.so.6 = /lib/i686/libc.so.6 (0x403a7000) libSM.so.6 = /usr/X11R6/lib/libSM.so.6 (0x404e2000) libICE.so.6 = /usr/X11R6/lib/libICE.so.6 (0x404eb000) projects/glut-1.0 == ls -l /usr/X11R6/lib/libGLU* lrwxrwxrwx1 root root 13 May 20 18:06 /usr/X11R6/lib/libGLU.so - libGLU.so.1.3 lrwxrwxrwx1 root root 13 May 20 18:06 /usr/X11R6/lib/libGLU.so.1 - libGLU.so.1.3 -rwxr-xr-x1 root root 565207 May 20 18:06 /usr/X11R6/lib/libGLU.so.1.3 = XFree86 Info /local/share/westall/projects/glut == xdpyinfo | more name of display::0.0 version number:11.0 vendor string:The XFree86 Project, Inc vendor release number:4020 XFree86 version: 4.2.0 maximum request size: 4194300 bytes motion buffer size: 256 bitmap unit, bit order, padding:32, LSBFirst, 32 image byte order:LSBFirst number of supported pixmap formats:7 supported pixmap formats: depth 1, bits_per_pixel 1, scanline_pad 32 depth 4, bits_per_pixel 8, scanline_pad 32 depth 8, bits_per_pixel 8, scanline_pad 32 depth 15, bits_per_pixel 16, scanline_pad 32 depth 16, bits_per_pixel 16, scanline_pad 32 depth 24, bits_per_pixel 32, scanline_pad 32 depth 32, bits_per_pixel 32, scanline_pad 32 == GLX Info /local/share/westall/projects/glut == glxinfo | more name of display: :0.0 display: :0 screen: 0 direct rendering: Yes server glx vendor string: SGI server glx version string: 1.2 server glx extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context client glx vendor string: SGI client glx version string: 1.2 client glx extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context GLX extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context OpenGL vendor string: VA Linux Systems, Inc. OpenGL renderer string: Mesa DRI Rage128 20010405 Pro AGP 1x x86/MMX/SSE OpenGL version string: 1.2 Mesa 3.4.2 OpenGL extensions: GL_ARB_multitexture, GL_ARB_transpose_matrix, GL_EXT_abgr, GL_EXT_clip_volume_hint, GL_EXT_compiled_vertex_array, GL_EXT_histogram, GL_EXT_packed_pixels, GL_EXT_polygon_offset, GL_EXT_rescale_normal, GL_EXT_stencil_wrap, GL_EXT_texture3D, GL_EXT_texture_env_add, GL_EXT_texture_object, GL_EXT_texture_lod_bias, GL_EXT_vertex_array, GL_MESA_window_pos, GL_MESA_resize_buffers, GL_NV_texgen_reflection, GL_PGI_misc_hints, GL_SGIS_pixel_texture, GL_SGIS_texture_edge_clamp glu version: 1.3 glu extensions: GLU_EXT_nurbs_tessellator, GLU_EXT_object_space_tess
Re: [Dri-devel] SSE on Athlons (and FreeBSD)
On Fri, 2002-07-12 at 06:22, Dave Jones wrote: On Thu, Jul 11, 2002 at 02:46:24AM -0600, Eric Anholt wrote: A better fix would be to actually enable SSE before FreeBSD does its feature flag detection. Linux does the following very early on.. You're thinking of the wrong issue. The issue fixed here is that we were looking in the wrong place for the SSE cpu option (bit 25 of AMD extended cpu features (0x8001) rather than bit 25 of standard cpu features (0x0001)). AMD's docs agree with this. I worked around this by ORing bit 25 of standard into the extended cpu features that we return. If the BIOS doesn't enable the SSE, it won't show up in the standard cpu options either. FreeBSD has the workaround for those broken bioses in the -current kernel at least, available as CPU_ATHLON_SSE_HACK option, which should be default soon (I have no idea why it isn't default already). -- Eric Anholt [EMAIL PROTECTED] http://people.freebsd.org/~anholt/dri/ --- This sf.net email is sponsored by:ThinkGeek Gadgets, caffeine, t-shirts, fun stuff. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] NURBs + Autonormal peculiarity
Mike Westall wrote: I have just rerun the nurb program on another machine which is running the distribution version of XFree86 4.2.0 which I downloaded as source and built on May 20, 2002. Accelerated rendering is on and working through an r128. This version appears to build libGLU 1.3 along with Mesa 3.4.2. The problem also persists there. So I think that the libGLU version is not the key -- but that probably Mesa 4.x may well contain the solution. Yes, that's it. I forgot that I overwrote my stock RH 7.3 X install with the latest DRI tree a few days ago. The DRI tree has Mesa 4.x. I just tested stand-alone Mesa 3.4.x and Mesa 4.0.3 and see the problem in the former, but not the later. -Brian --- This sf.net email is sponsored by:ThinkGeek Gadgets, caffeine, t-shirts, fun stuff. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64
On Fri, 12 Jul 2002, José Fonseca wrote: On Thu, Jul 11, 2002 at 06:34:40PM -0400, Leif Delgass wrote: On Thu, 11 Jul 2002, Brian Paul wrote: Leif Delgass wrote: I just discovered that the glean failures in blendFunc, logicOp, orthoPosRandTris, orthoPosRandRects, orthoPosTinyQuads, and polygonOffset are the result of an off-by-one error in the y screen coordinates. If I add one to the Y coordinate in the viewport conversion to screen coordinates, these tests all pass. However, it breaks the scissor test and the orthoPos[H,V]Lines and orthoPosPoints tests still fail (which could be a result of the implementation of points and lines with triangles/quads). It also seems to leave a row of pixels at the top of the window which isn't drawn on, but is cleared. The stipple test still has the same problem because lines still aren't conformant. I'm still a little puzzled as to where the off-by-one error actually originates, but this narrows down the problem a lot. The Y-coordinate error may be less than one. Most of the DRI hardware drivers need X/Y coordinates biased by a small amount in order to make hardware rasterization and software rasterization coincide. So, something like 0.75 or 0.875 might work better. Yeah, I just realized that. I'm playing with X and Y subpixel offsets to try and find a combination that fixes the most problems without breaking tests that worked. :) Leif, note that at least with the vertices generated by mach64_translate_vertex (i.e., converted from the VB into SWVertex during a fallback) in the new template they will already be rounded off into the chip precision, so that can make a difference already. You'll perhaps want look into that as well. Note also that the native vertex format stuff is finished, and is now enabled by default in the CVS. The old behavior is still there and one can change the MACH64_NATIVE_VTXMFT macro in mach64_context.h to enable it but that code won't stay much longer - because the new code is much more optimized and has some fixes which I didn't bother to propagate to the old code, and also to make place for new optimizations (such as primitive strips and so on). Well, I added these offsets: SUBPIXEL_X 0.0125 SUBPIXEL_Y 0.15 ...and that's enough to make every glean test pass except polygonOffset (and texEnv, but that one's due to non-conformant hardware). However, I still see gaps in e.g. the Mesa tunnel demo and the lament xscreensaver hack (and probably lots of other places). The lines in Allen's stipple test now always overlap exactly. Jose, I think your changes reduced the offset necessary, but it does need a small offset to pass the tests. Actually I think the line tests start working at a smaller offset than some of the other tests. I checked in some other changes as well, one of which was to put the primitive type defines in the drm header and common header. We have the vertsize in the SAREA, and between that and the primitive list, I think the drm should be able to figure out how to add commands to the vertex buffers. As you say, we can use send fewer vertices to the card by implementing primitive strips. I just made the defines mirror the GL primitive defines, but we could reduce them to just the ones we'll implement. One other thing: I noticed you were supporting line/point size in the new primitive functions, so I removed the code from mach64_context.c that was overwriting the Mesa defaults with a max size/width of 1. However, for large, unaliased points, we need to have points implemented as quads instead of triangles (try drawing a 10 pixel point and compare it to indirect). Oh, I also fixed polygon stippling to work as a software fallback. -- Leif Delgass http://www.retinalburn.net --- This sf.net email is sponsored by:ThinkGeek Gadgets, caffeine, t-shirts, fun stuff. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64: multi texture crash with after last update
Felix Kühling wrote: I got also a bit worried about using string instructions without clearing the direction flag. Is there any convention that prevents an application from setting the direction flag. If not, it might happen that esi and edi are decremented. On Fri, 12 Jul 2002 11:51:13 +0100 José Fonseca [EMAIL PROTECTED] wrote: On Fri, Jul 12, 2002 at 04:28:25AM +0200, Felix Kühling wrote: Hi, just updated after reading José's mail about the MACH64_NATIVE_VTXMFT and tried running some apps. q3demo and quake2 crashed with multi textures enabled: q3demo.x86: mach64_tris.c:518: mach64_draw_triangle: Assertion `vb == vbchk' failed. I found the problem in the COPY_VERTEX macro. The movsl instruction doesn't decrement %ecx when there is no rep prefix, so you have to decrease afterwards. Here's the fix: [...] It's now on CVS. I though that the %ecx decrement was already handled by the 'movsl' instruction and that the 'rep' prefix just added the conditional jump... I missed the start of this... Is this something that should be fixed in the other drivers as well? Keith --- This sf.net email is sponsored by:ThinkGeek Gadgets, caffeine, t-shirts, fun stuff. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] CVS tips.
--- Keith Whitwell [EMAIL PROTECTED] wrote: Michal Kozlowski wrote: On Thu, 11 Jul 2002, Stefan Lange wrote: compiling from cvs shouldn't be a problem, I just followed the DRI Compilation Guide from the website and everything went fine (you might have to compile the kernel drm-module manually, but that's no trouble) Completed the compile didn't help me any still does that same thing, did you find that you had to remove some misplaced and from some files? If you've got those in your files it means CVS has somehow gotten confused. If you do something like a 'cvs update' from the top level directory, you should get *NO* lines that look like: M xc/asdf/adsf/adsf/somefile.c Note the capital 'M'. I bet you have a few. Remove them update again. Keith or just run update with -C, this will take all the M xc/asdf/adsf/adsf/somefile.c and replace them. also -P -r are good to have. read the man page for more info. __ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com --- This sf.net email is sponsored by:ThinkGeek Gadgets, caffeine, t-shirts, fun stuff. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Tribes 2 Lockups: Help me pinpoint the problem...
--- Daniel Kasak [EMAIL PROTECTED] wrote: Marc Poulhiès wrote: I know that closed source drivers from ati are not discussed here, but with my radeon 8500 and tribes2 i have exactly the same probleme. Maybe this is a probleme from tribes2 and not the dri :) Maybe. But it _used_ to work fine under xfree86 4.1.0 4.2.0. Has anyone had any success with Tribes 2 and the Radeon TCL drivers? There have been some other program related problems, that are only visible when using TCL. Read the list from last week there is a good example, Tux Racer. Since the problem only happes with this one app we need to know more about this app. File another bug report against the app, giving them the dri-devel e-mail address as they will want to talk to us, once they duplicate your findings. Lets not focus too much on where the problem is, but on what the problem is. For all things there are many solutions. For some DRI related bugs the fix can be maid in the app or driver. __ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com --- This sf.net email is sponsored by:ThinkGeek Gadgets, caffeine, t-shirts, fun stuff. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64
On Fri, 12 Jul 2002, José Fonseca wrote: On Fri, Jul 12, 2002 at 03:55:02PM -0400, Leif Delgass wrote: [...] Well, I added these offsets: SUBPIXEL_X 0.0125 SUBPIXEL_Y 0.15 ...and that's enough to make every glean test pass except polygonOffset (and texEnv, but that one's due to non-conformant hardware). However, I still see gaps in e.g. the Mesa tunnel demo and the lament xscreensaver hack (and probably lots of other places). The lines in Allen's stipple test now always overlap exactly. Jose, I think your changes reduced the offset necessary, but it does need a small offset to pass the tests. Actually I think the line tests start working at a smaller offset than some of the other tests. I found it strange that it requires such values of offset, especially the 0.15. Could it be that we are doing the rounding wrong somewhere? I arrived at these through trial and error. There's a range of offsets that will work, but I tried to choose ones at the bottom of the range. Maybe there's a more scientific way to do this. I checked in some other changes as well, one of which was to put the primitive type defines in the drm header and common header. We have the vertsize in the SAREA, and between that and the primitive list, I think the drm should be able to figure out how to add commands to the vertex buffers. As you say, we can use send fewer vertices to the card by implementing primitive strips. I just made the defines mirror the GL primitive defines, but we could reduce them to just the ones we'll implement. One other thing: I noticed you were supporting line/point size in the new primitive functions, so I removed the code from mach64_context.c that was overwriting the Mesa defaults with a max size/width of 1. However, for large, unaliased points, we need to have points implemented as quads instead of triangles (try drawing a 10 pixel point and compare it to indirect). It's being done as a quad, so there must be a bug somewhere. At the time I didn't manage to test bigger points - now I know why! OK, it must be a problem with one of vertices then. Also, I'm noticing artifacts in quake3 with multitexture, looks like bad vertices here and there. I'll see if I can narrow it down at all. It's visible on the title of the menu screen and with lightmap lighting. -- Leif Delgass http://www.retinalburn.net --- This sf.net email is sponsored by:ThinkGeek Gadgets, caffeine, t-shirts, fun stuff. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64: multi texture crash with after last update
On Fri, Jul 12, 2002 at 02:01:53PM -0600, Keith Whitwell wrote: Felix Kühling wrote: I got also a bit worried about using string instructions without clearing the direction flag. Is there any convention that prevents an application from setting the direction flag. If not, it might happen that esi and edi are decremented. On Fri, 12 Jul 2002 11:51:13 +0100 José Fonseca [EMAIL PROTECTED] wrote: [...] I though that the %ecx decrement was already handled by the 'movsl' instruction and that the 'rep' prefix just added the conditional jump... I missed the start of this... Is this something that should be fixed in the other drivers as well? The bug that Felix found first is specific of Mach64, on a x86 specific macro equivalent to the COPY_DWORDS existing in the other drivers, in the _tris.c file. But his later statement about clearing the direction flag regards every card that uses the 'rep; movsl' assembly instructions, such as in the COPY_DWORDS macro. This seems to be a tricky issue though which has been discussed in the linux kernel sometimes already: http://marc.theaimsgroup.com/?l=linux-kernelm=94388449615903w=2 http://marc.theaimsgroup.com/?l=linux-kernelm=94371268003189w=2 http://marc.theaimsgroup.com/?l=linux-kernelm=88995996331639w=2 http://marc.theaimsgroup.com/?l=linux-kernelm=88981148900284w=2 My understanding of above is that althought issuing 'cld' is somewhat costy, we _can't_ assume that the direction flag is clear, so we need to issue it at least once in each subroutine where the COPY_DWORDS macro is used, and after calling any foreign code on that subroutines. José Fonseca --- This sf.net email is sponsored by:ThinkGeek Gadgets, caffeine, t-shirts, fun stuff. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64
On Fri, Jul 12, 2002 at 03:55:02PM -0400, Leif Delgass wrote: [...] Well, I added these offsets: SUBPIXEL_X 0.0125 SUBPIXEL_Y 0.15 ...and that's enough to make every glean test pass except polygonOffset (and texEnv, but that one's due to non-conformant hardware). However, I still see gaps in e.g. the Mesa tunnel demo and the lament xscreensaver hack (and probably lots of other places). The lines in Allen's stipple test now always overlap exactly. Jose, I think your changes reduced the offset necessary, but it does need a small offset to pass the tests. Actually I think the line tests start working at a smaller offset than some of the other tests. I found it strange that it requires such values of offset, especially the 0.15. Could it be that we are doing the rounding wrong somewhere? I checked in some other changes as well, one of which was to put the primitive type defines in the drm header and common header. We have the vertsize in the SAREA, and between that and the primitive list, I think the drm should be able to figure out how to add commands to the vertex buffers. As you say, we can use send fewer vertices to the card by implementing primitive strips. I just made the defines mirror the GL primitive defines, but we could reduce them to just the ones we'll implement. One other thing: I noticed you were supporting line/point size in the new primitive functions, so I removed the code from mach64_context.c that was overwriting the Mesa defaults with a max size/width of 1. However, for large, unaliased points, we need to have points implemented as quads instead of triangles (try drawing a 10 pixel point and compare it to indirect). It's being done as a quad, so there must be a bug somewhere. At the time I didn't manage to test bigger points - now I know why! Oh, I also fixed polygon stippling to work as a software fallback. José Fonseca --- This sf.net email is sponsored by:ThinkGeek Gadgets, caffeine, t-shirts, fun stuff. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: what is hyper-z?
Howzit? what is hyper-z? a proprietary texture-compression function of the r200? well, as you expected, performance is exactly the same after the checkout as before HyperZ has 3 components: Hierarchical Z Discards hidden pixels instead of sending them to be rendered. Z-Compression Performs lossless compression on the Z co-ordinates. Fast Z-Clear Uses a fast method of clearing the Z buffer. Texture compression is something else, ie S3TC or FXTC The Radeon (R100) supports S3TC. Liam it depends --- This sf.net email is sponsored by:ThinkGeek Gadgets, caffeine, t-shirts, fun stuff. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: The Radeon LE? (Mike Mestnik) aka Radeon naming scheme
# # List of PCI ID's # # Maintained by Martin Mares [EMAIL PROTECTED] and other volunteers from the # Linux PCI ID's Project at http://pciids.sf.net/. New data are always # welcome (if they are accurate), we're eagerly expecting new entries, # so if you have anything to contribute, please visit the home page or # send a diff -u against the most recent pci.ids to [EMAIL PROTECTED] # # Daily snapshot on Tue 2002-07-09 10:00:05 # This isn't the only place to find PCI IDs but it seems to explain all the hardware I have. You can take a look at the list if you want, but there's not mention of a card maid by ATI with an LE in it's name. The name really isn't important it's the meaning behind the name. I've got a Radeon 7500 QW Product ID 0x5157, and I also have A Radeon QL Product ID 0x514C, I didn't look at the sub device to see if That was accurate. I would like to know what the Product ID of your Radeon LE card is and I'd like to add it to the data base. If it is 0x514C then where did you learn that it's also called an LE, I'm just curious? Please in the future make it clear what your talking about to avoid confusion, it seams to me that the LE's work while the QW's don't It could be that they have different Product IDs, or that they just need to be treated as if they did. Thank you for your help in sorting this ought. I refer to my earlier email explaining the Radeon naming scheme. This is from the webpage version which I dont think Ian has had a chance to put up yet: snip Radeon Naming Scheme Original Radeons: Radeon VE (1 texture pipeline, no TCL) Radeon SDR Radeon DDR / LE Rereleased Radeons: Radeon 7000 (1 texture pipeline, no TCL) Radeon 7200 (SDR) Radeon 7500 (DDR) The only differences between the releases are more RAM and higher clock speeds (possible due to a manufacturing process shrink) on the 7X00 cards. You also get fancy versions of most of these cards eg VIVO, AIW, etc, this is just added functionality ie stick on a tv tuner, a couple of chips. The reason for the renaming is to simplify matters for end users i.e. bigger number = better / faster. Furthermore 7X00 denotes a R100 based card and 8X00 denotes a R200 based card. snip The key line here is: Radeon DDR / LE In other words they are the same card. Legend has is that ATI handed off sonme R100 chips to various companies to make Radeons with them. Up until this point all Radeons were made by ATI. These Radeons would be known as Radeon LE. They differed in that they had a different clock speed, and the silkscreen logo on them was without ATI, ie it only had Radeon on it not ATI Radeon. But the major diffence is that the BIOS had been modified so that the HyperZ functions (see other email) would not work under DirectX, but would still work under OpenGL. Basic product differentation. But *nix doesnt have Direct X so it doesnt matter. AFAIK you can flash your Radeon LE with the Radeon DDR BIOS and then it obviously wont have this problem. WRT to the 8500LE, as has been pointed out its clocked lower, I think this card is more similar to the ATI 8500 than the Radeon LE is to the Radeon DDR. I assume that I'm going to have to add this at some point to the Radeon naming scheme page. Liam it depends --- This sf.net email is sponsored by:ThinkGeek Gadgets, caffeine, t-shirts, fun stuff. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Radeon 8500 binary snapshots now available - Status page.
Great work Keith. What I've done so far is to extend the existing radeon interfaces to accept validate the new state required for the r200, and a couple of other minor changes. This is probably the minimal set of changes to get a working r200 driver. It would seem that driver development for the R200 similar to the R100, considering how quickly this driver came out. Is this correct? A large part of this difference is presumably due to HyperZ - something that we can't implement in an open driver. Could you please explain why this is, I'd like to know and I'll add it to the documentation, I assume the same holds true for the R100. Do you think a R200_dri_features page (like the one for the R100) would be in order, would you like one? Liam it depends --- This sf.net email is sponsored by:ThinkGeek Gadgets, caffeine, t-shirts, fun stuff. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64
On Fri, 12 Jul 2002, Leif Delgass wrote: It's being done as a quad, so there must be a bug somewhere. At the time I didn't manage to test bigger points - now I know why! OK, it must be a problem with one of vertices then. Also, I'm noticing artifacts in quake3 with multitexture, looks like bad vertices here and there. I'll see if I can narrow it down at all. It's visible on the title of the menu screen and with lightmap lighting. I fixed the points problem. Just had to swap the third vertex in the first tri with the vertex for the second tri. -- Leif Delgass http://www.retinalburn.net --- This sf.net email is sponsored by:ThinkGeek Gadgets, caffeine, t-shirts, fun stuff. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Microsoft IP claims over OpenGL
Microsoft has been progressively claiming IP ownership of parts of the OpenGL API. (See http://news.zdnet.co.uk/story/0,,t269-s2118968,00.html) Although the parts they claim are things like vertex programming - features that aren't present in older cards such as Mach64 -, it seems obvious that these are features very important in the current and next generation of graphics cards. I would like to know your opinion about the influence this may have for the DRI and Mesa3D projects in particular, and for the OpenGL API in general. José Fonseca --- This sf.net email is sponsored by:ThinkGeek Gadgets, caffeine, t-shirts, fun stuff. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Microsoft IP claims over OpenGL
=?iso-8859-1?Q?Jos=E9?= Fonseca writes: Microsoft has been progressively claiming IP ownership of parts of the OpenGL API. (See http://news.zdnet.co.uk/story/0,,t269-s2118968,00.html) Although the parts they claim are things like vertex programming - features that aren't present in older cards such as Mach64 -, it seems obvious that these are features very important in the current and next generation of graphics cards. I would like to know your opinion about the influence this may have for the DRI and Mesa3D projects in particular, and for the OpenGL API in general. José Fonseca The question is if those patents are US only or if they are valid in the rest of the world. Since they are software patents, they might not be. This would mean that development would have to be done outside the US and drivers could not be offered inside the US, except for research purposes of course. Marcus -- /\ | Dr. Marcus O.C. Metzler| | ||---| | [EMAIL PROTECTED]| http://www.metzlerbros.de/| \/ --- This sf.net email is sponsored by:ThinkGeek Gadgets, caffeine, t-shirts, fun stuff. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Microsoft IP claims over OpenGL
On Sat, Jul 13, 2002 at 12:36:53AM +0100, José Fonseca wrote: | I would like to know your opinion about the influence this may have for | the DRI and Mesa3D projects in particular, and for the OpenGL API in | general. Of course Microsoft would love to see OpenGL disappear, and has been working toward that for many years. It's wise not to be naive about Microsoft's intentions. However, it's not clear yet whether this particular move represents a new threat. Vendors are required to notify the OpenGL ARB when they believe they have intellectual property claims on any feature that's being proposed to the ARB. (This is intended to prevent vendors from allowing a feature to be included in the standard, then blackmailing all the other vendors after they've shipped it.) At this point, that's all Microsoft has done. If they had a history of operating in good faith, then there'd be no great reason for concern. Unfortunately, the process of licensing intellectual property to other ARB vendors is not well-defined by the ARB bylaws. So Microsoft could cause problems by (a) delaying the licensing process so as to halt progress on new versions of OpenGL, (b) requiring unacceptable licensing terms (high royalties, cross-licensing of other intellectual property, use only under Windows, etc.), or (c) licensing to only a few selected vendors (excluding open source vendors, for example). So far Microsoft has been using tactic (a). You'll know it's time to worry when there are signs that Microsoft is using tactics (b) or (c). Allen --- This sf.net email is sponsored by:ThinkGeek Gadgets, caffeine, t-shirts, fun stuff. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Pr0n
Hi There, Thought you might want to take a look at this incredible adult site http://80.71.65.55/ Have Fun, Vena 4458yTiM2-799ecEk9801nHsj0-398SebL3907PDKr3-455axGl4521sKFV5-093l60 --- This sf.net email is sponsored by:ThinkGeek Gadgets, caffeine, t-shirts, fun stuff. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
