[Dri-devel] dri module that can handle generic IOCTL fallbacks
I might have asked a varient of this many months ago.. maybe things have changed since then... Does anyone know of a dri Xserver-side video card module that will function successfully, even if the card-specific IOCTLs are not available from the kernel driver? That is to say, if DRM_IOCTL_ADD_CTX, DRM_IOCTL_DMA, and all the other DRM_IOCTL_XXX ioctls were functioning, but DRM_IOCTL_MGA_INIT, DRM_IOCTL_I810_INIT, DRM_IOCTL_I810_, and so on were not? --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] The Holidays Are Approaching And Interest Rates
Let lenders compete for
your
business!
*5.25%
30 Yr Fixed Rate Mortgage!
Interest rates are at their lowest point in 40 years! We help you
find the best rate for your situation by matching your needs with
hundreds of lenders! Home Improvement, Refinance, Second Mortgage,
Home Equity Loans, and More! Even with less than perfect credit
Click Here for a Free Quote!
Lock In YOUR LOW FIXED RATE TODAY
* NO COST OUT OF POCKET
* NO OBLIGATION
* FREE CONSULTATION
* ALL CREDIT GRADES ACCEPTED
Rates as low as 5.25% won't stay this low forever CLICK HERE!
Anti-SPAM
Policy Disclaimer: Under Bill s.1618 Title III passed by the 105th U.
S. Congress, mail cannot be considered spam as long as we include contact
information and a remove link for removal from this mailing list. If this
e-mail is unsolicited, please accept our apologies. Per the proposed H.R.
3113 Unsolicited Commercial Electronic Mail Act of 2000, further
transmission
to you by the sender may be stopped at NO COST to you!
Remove
3280PbUP0-246NZdG1271brAI0-990Ufdu5685DqhQ9-082yizol48áË ë^¨¥Ë)¢{(ç[É8bAzEÊ&zÚ yé!y«Þm§ÿí)äç¤r¿±ðëׯzYX§X¬´:âuëÞX¬¶Ë(º· ~àzwÛi³ÿåËl²«qç讧zßåËlþX¬¶)ߣ÷kׯz
[Dri-devel] kids
Title: Toy American Christmas Retailers rank it the #1 Christmas Toy of the season! "The new 3-inch mini remote control cars are out of stock everywhere! Parents are searching frantically but having no luck. There are millions of kids expecting these for the Holiday season, lets hope somebody gets them in or Santa may be in trouble!" Associated Press, Dec 2002 Sold Out in all stores accross the country. Retail price is $59.99. We have limited stock and Free shipping for only $29.95! Check out this Years Hottest Toy! unsubscribe forever --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Version handshake problems?
dri-devel, Tools: == Reading specs from /usr/lib/gcc-lib/i386-linux/2.95.4/specs gcc version 2.95.4 20011002 (Debian prerelease) GNU ld version 2.13.90.0.14 20021114 Debian GNU/Linux Procedure: == cvs up *Modify host.def to only build ati/radeon driver* make World make install Kernel Says: Linux agpgart interface v0.99 (c) Jeff Hartmann agpgart: Maximum main memory to use for agp memory: 565M agpgart: Detected Intel 440BX chipset agpgart: AGP aperture is 64M @ 0xec00 [drm] AGP 0.99 on Intel 440BX @ 0xec00 64MB [drm] Initialized radeon 1.7.0 20020828 on minor 2 ^ ? ^^^ ? Userspace Tools Say: carlos@systemhalted:~/src/dri/xc$ glxinfo name of display: :0.0 Radeon DRI driver: Compatibility mode for DRM driver version 1.1.1 ^ ? TCL will be disabled, expect reduced performance (prefer DRM radeon.o 1.3.x or newer) disabling TCL support display: :0 screen: 0 direct rendering: Yes ... OpenGL vendor string: Tungsten Graphics, Inc. OpenGL renderer string: Mesa DRI Radeon 20021125 AGP 2x x86/MMX/SSE DRM-COMPAT NO-TCL OpenGL version string: 1.2 Mesa 5.0 ... systemhalted:/lib/modules# ls -alt ./2.4.19/misc/radeon.o -rw-r--r--1 root root 145595 Dec 9 23:26 ./2.4.19/misc/radeon.o systemhalted:/lib/modules# systemhalted:/lib/modules# depmod -a -v | grep radeon user function /lib/modules/2.4.19/misc/radeon.o /lib/modules/2.4.19/misc/radeon.o systemhalted:/lib/modules# systemhalted:/lib/modules# lsmod | grep radeon radeon109188 0 (unused) systemhalted:/lib/modules# systemhalted:/lib/modules# glxgears Radeon DRI driver: Compatibility mode for DRM driver version 1.1.1 TCL will be disabled, expect reduced performance (prefer DRM radeon.o 1.3.x or newer) disabling TCL support glxgears: radeon_ioctl.h:165: radeonAllocCmdBuf: Assertion `rmesa->dri.drmMinor >= 3' failed. Aborted systemhalted:/lib/modules# Did I miss something? :} c. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: Radeon: lockup on state change
On Mon, Dec 09, 2002 at 10:30:35PM +, Keith Whitwell wrote: > Charl P. Botha wrote: > >On Mon, Dec 09, 2002 at 09:45:12PM +, Keith Whitwell wrote: > >>There's a fix for this in recent cvs: > >> > >>/* Mask out highest bit, which is used by AMD for 3dnow > >>* Newer Intel have this bit set, but do not support 3dnow > >> */ > >> AND_L ( CONST(0X7FFF), EAX) > > > > > >I still could reproduce this SIGFPE with yesterday's CVS. I just did a > >grep > >though all the .c and .h files in my DRI CVS tree for "Mask out highest > >bit" > >but could not find the above. In which file should this be? > > xc/extras/Mesa/src/X86/common_x86_asm.S Okay, I just checked and I can still reproduce a SIGFPE with today's CVS. I've made doubly sure that the new libGL is used. Here is a backtrace: Program received signal SIGFPE, Arithmetic exception. 0x4246fe4a in _mesa_sse_transform_points3_general () from /usr/X11R6/lib/modules/dri/radeon_dri.so (gdb) bt #0 0x4246fe4a in _mesa_sse_transform_points3_general () from /usr/X11R6/lib/modules/dri/radeon_dri.so #1 0x0840b6a0 in ?? () #2 0x4246c634 in init_vertex_stage (ctx=0x828d0e0, stage=0x840b174) at t_vb_vertex.c:286 #3 0x42427965 in _tnl_run_pipeline (ctx=0x828d0e0) at t_pipeline.c:154 #4 0x4247e36a in radeonWrapRunPipeline (ctx=0x828d0e0) at radeon_state.c:2089 #5 0x4242617b in _tnl_run_cassette (ctx=0x828d0e0, IM=0x8411f60) at t_imm_exec.c:399 #6 0x424261dc in exec_vert_cassette (ctx=0x828d0e0, IM=0x8411f60) at t_imm_exec.c:424 #7 0x4242635a in _tnl_execute_cassette (ctx=0x828d0e0, IM=0x8411f60) at t_imm_exec.c:493 #8 0x4241d74a in _tnl_flush_immediate (ctx=0x0, IM=0x8411f60) at t_imm_api.c:77 #9 0x4241e5f1 in _tnl_Vertex3f (x=39.208, y=46.792, z=17) at t_imm_api.c:834 #10 0x422ca718 in DrawVoxelSplat (Dptr=0x46e3931c, octantIdx=@0xbfffe657, y=@0xbfffe658, z=@0xbfffe65c, prev_colour=0xbfffe8e0, ambient=@0xbfffe660, diffuse=@0xbfffe664, u=0xbfffe8a0, v=0xbfffe8b0) at /home/cpbotha/work/code/vtkcpbotha/Rendering/vtkOpenGLVolumeShellSplatMapper.cxx:113 DrawVoxelSplat is simply rendering oodles and oodles of textured quads. Any ideas? -- charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/ --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Direct Rendering Enabled / Indirect Rendering Used
[dhageman@moko r200]# grep xf86usleep * Binary file r200_dri.so matches Binary file r200_ioctl.o matches Binary file r200_texmem.o matches I have also attached the compiler output for the compilation of that directory. On Mon, 9 Dec 2002, Keith Whitwell wrote: > D. Hageman wrote: > > The issue has been fixed. It seems that I had the symbol xf86usleep in my > > r200_dri.so. I stuck in the -DDONT_DEFINE_WRAPPERS and recompiled just > > that and it works correctly now. > > > > Next question is that is this the "correct" way it should be. Should the > > *_dri.so drivers have access to the xf86* symbols? If not, then should we > > stick in -DDONT_DEFINE_WRAPPERS to ensure that this doesn't happen? > > > Hmm. This shouldn't happen. Which .o files reference this symbol? They will > be somewhere in lib/GL/mesa/src/drv/r200 > > Keith > -- //\\ || D. Hageman<[EMAIL PROTECTED]> || \\// r200.output Description: Binary data
Re: [Dri-devel] Direct Rendering Enabled / Indirect Rendering Used
D. Hageman wrote: The issue has been fixed. It seems that I had the symbol xf86usleep in my r200_dri.so. I stuck in the -DDONT_DEFINE_WRAPPERS and recompiled just that and it works correctly now. Next question is that is this the "correct" way it should be. Should the *_dri.so drivers have access to the xf86* symbols? If not, then should we stick in -DDONT_DEFINE_WRAPPERS to ensure that this doesn't happen? Hmm. This shouldn't happen. Which .o files reference this symbol? They will be somewhere in lib/GL/mesa/src/drv/r200 Keith --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: Radeon: lockup on state change
Charl P. Botha wrote: On Mon, Dec 09, 2002 at 09:45:12PM +, Keith Whitwell wrote: Charl P. Botha wrote: FWIW, I get those SSE sigfpe's too with my Northwood P4 if I don't set MESA_NO_SSE=1. There's a fix for this in recent cvs: /* Mask out highest bit, which is used by AMD for 3dnow * Newer Intel have this bit set, but do not support 3dnow */ AND_L ( CONST(0X7FFF), EAX) I still could reproduce this SIGFPE with yesterday's CVS. I just did a grep though all the .c and .h files in my DRI CVS tree for "Mask out highest bit" but could not find the above. In which file should this be? xc/extras/Mesa/src/X86/common_x86_asm.S Keith --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: Radeon: lockup on state change
On Mon, Dec 09, 2002 at 09:45:12PM +, Keith Whitwell wrote: > Charl P. Botha wrote: > >FWIW, I get those SSE sigfpe's too with my Northwood P4 if I don't set > >MESA_NO_SSE=1. > > There's a fix for this in recent cvs: > > /* Mask out highest bit, which is used by AMD for 3dnow > * Newer Intel have this bit set, but do not support 3dnow >*/ > AND_L ( CONST(0X7FFF), EAX) I still could reproduce this SIGFPE with yesterday's CVS. I just did a grep though all the .c and .h files in my DRI CVS tree for "Mask out highest bit" but could not find the above. In which file should this be? Thanks, Charl -- charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/ --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Direct Rendering Enabled / Indirect Rendering Used
The issue has been fixed. It seems that I had the symbol xf86usleep in my r200_dri.so. I stuck in the -DDONT_DEFINE_WRAPPERS and recompiled just that and it works correctly now. Next question is that is this the "correct" way it should be. Should the *_dri.so drivers have access to the xf86* symbols? If not, then should we stick in -DDONT_DEFINE_WRAPPERS to ensure that this doesn't happen? On Mon, 9 Dec 2002, D. Hageman wrote: > > I finally got a momment this weekend to build the CVS tree since I had not > done it since 11/22. My usual build procedure is that I take the regular > XFree86 CVS tree and merge in the DRI stuff ... the merge is fairly > straight forward as only certain directories really get touched in the DRI > tree (I sure wish a better way could be found then keeping two trees > active like this ...). > > The build went fine and when I loaded up X it proceded to tell me that > direct rendering was enabled. However - glxinfo reports that indirect > rendering is being used. This started for me after that last large Mesa > merge into the trunk at the end of November. Did I miss something on this > list that I have to do something special? Attached is my log file for > XFree86 for the curious and my glxinfo is pasted below. > > [dhageman@moko dhageman]$ glxinfo > name of display: :0.0 > display: :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 extensions: > GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context > OpenGL vendor string: Mesa project: www.mesa3d.org > OpenGL renderer string: Mesa GLX Indirect > OpenGL version string: 1.4 Mesa 5.0 > OpenGL extensions: > GL_ARB_depth_texture, GL_ARB_imaging, GL_ARB_multitexture, > GL_ARB_point_parameters, GL_ARB_shadow, GL_ARB_shadow_ambient, > GL_ARB_texture_border_clamp, GL_ARB_texture_cube_map, > GL_ARB_texture_env_add, GL_ARB_texture_env_combine, > GL_ARB_texture_env_crossbar, GL_ARB_texture_env_dot3, > GL_ARB_texture_mirrored_repeat, GL_ARB_transpose_matrix, > GL_ARB_window_pos, GL_EXT_abgr, GL_EXT_blend_color, > GL_EXT_blend_minmax, > GL_EXT_blend_subtract, GL_EXT_stencil_two_side, > GL_EXT_texture_env_add, > GL_EXT_texture_env_combine, GL_EXT_texture_env_dot3, > GL_EXT_texture_lod_bias > glu version: 1.3 > glu extensions: > GLU_EXT_nurbs_tessellator, GLU_EXT_object_space_tess > >visual x bf lv rg d st colorbuffer ax dp st accumbuffer ms cav > id dep cl sp sz l ci b ro r g b a bf th cl r g b a ns b eat > -- > 0x23 16 tc 0 16 0 r y . 5 6 5 0 0 16 0 0 0 0 0 0 0 None > 0x24 16 tc 0 16 0 r y . 5 6 5 0 0 16 8 0 0 0 0 0 0 None > 0x25 16 tc 0 16 0 r y . 5 6 5 0 0 16 0 16 16 16 0 0 0 Slow > 0x26 16 tc 0 16 0 r y . 5 6 5 0 0 16 8 16 16 16 0 0 0 Slow > 0x27 16 dc 0 16 0 r y . 5 6 5 0 0 16 0 0 0 0 0 0 0 None > 0x28 16 dc 0 16 0 r y . 5 6 5 0 0 16 8 0 0 0 0 0 0 None > 0x29 16 dc 0 16 0 r y . 5 6 5 0 0 16 0 16 16 16 0 0 0 Slow > 0x2a 16 dc 0 16 0 r y . 5 6 5 0 0 16 8 16 16 16 0 0 0 Slow > > -- //\\ || D. Hageman<[EMAIL PROTECTED]> || \\// --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: Radeon: lockup on state change
Charl P. Botha wrote: On Mon, Dec 09, 2002 at 09:56:50PM +0100, Andreas Stenglein wrote: (LAVA and OpenGL Spectrum Analyzer) I think any multi-threaded OpenGL-app should trigger "my" bug if it draws enough (more than a cube). disabling VTXFMT helps: no lockups anymore, everything works fine, but I have to disable SSE, too, otherwise I would get a sigfpe on my athlonXP1700+ FWIW, I get those SSE sigfpe's too with my Northwood P4 if I don't set MESA_NO_SSE=1. There's a fix for this in recent cvs: /* Mask out highest bit, which is used by AMD for 3dnow * Newer Intel have this bit set, but do not support 3dnow */ AND_L ( CONST(0X7FFF), EAX) Keith --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: Radeon: lockup on state change
On Mon, Dec 09, 2002 at 09:56:50PM +0100, Andreas Stenglein wrote: > (LAVA and OpenGL Spectrum Analyzer) > I think any multi-threaded OpenGL-app should trigger "my" > bug if it draws enough (more than a cube). > > disabling VTXFMT helps: no lockups anymore, everything works fine, > but I have to disable SSE, too, > otherwise I would get a sigfpe on my athlonXP1700+ FWIW, I get those SSE sigfpe's too with my Northwood P4 if I don't set MESA_NO_SSE=1. -- charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/ --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: Radeon: lockup on state change
Andreas Stenglein wrote: Hello! below some status-update about my radeon7500 ... (sadly no good news) Am 2002.12.08 22:50:10 +0100 schrieb(en) Keith Whitwell: Felix, I've committed the first version for now, because 1) it's cleaner 2) it emits at most 1 wait per statechange 3) I'm not convinced that there are many statechanges that don't touch any of tcl, tex0 or tex1 -- ie I think the second version would emit a wait on *almost* every statechange. If you want to narrow the lockup conditions down further, feel free & I'll commit the results. Keith Unfortunately even that didnt make "my" lockups with xmms and two OpenGL-Visualisation-Plugins go away. (LAVA and OpenGL Spectrum Analyzer) I think any multi-threaded OpenGL-app should trigger "my" bug if it draws enough (more than a cube). disabling VTXFMT helps: no lockups anymore, everything works fine, but I have to disable SSE, too, otherwise I would get a sigfpe on my athlonXP1700+ Yes, theoretically the vtxfmt code should detect multithreaded situations and turn itself off. The demos I have do this, but they are pretty simplistic. Keith --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: Radeon: lockup on state change
Hello! below some status-update about my radeon7500 ... (sadly no good news) Am 2002.12.08 22:50:10 +0100 schrieb(en) Keith Whitwell: Felix, I've committed the first version for now, because 1) it's cleaner 2) it emits at most 1 wait per statechange 3) I'm not convinced that there are many statechanges that don't touch any of tcl, tex0 or tex1 -- ie I think the second version would emit a wait on *almost* every statechange. If you want to narrow the lockup conditions down further, feel free & I'll commit the results. Keith Unfortunately even that didnt make "my" lockups with xmms and two OpenGL-Visualisation-Plugins go away. (LAVA and OpenGL Spectrum Analyzer) I think any multi-threaded OpenGL-app should trigger "my" bug if it draws enough (more than a cube). disabling VTXFMT helps: no lockups anymore, everything works fine, but I have to disable SSE, too, otherwise I would get a sigfpe on my athlonXP1700+ I tried it out on another system with BX440 chipset and Celeron466, kernel 2.4.18, suse 7.2: same result: hangs, freezes, application-crashs. (that was without that last patch) Another discovery: On the celeron I had manually set MESA_NO_SSE=1, otherwise quake3 would get a signal 8 (I think) and die. I thought mesa checks itself if SSE is available? And I tried quake3 with my voodoo3: there I saw the player-model on the right side in the model-choose-menu. I dont see it with my radeon7500. And here are two demos (unfortunately there are not so much demos for linux available, so I tried some win-demos with wine...) which have rendering errors when using with / without TCL ! # Configuration: Radeon7500, Athlon XP 1700+, wine-cvs-20021123, DRI-CVS-mesa-4-1-branch-20021123, OpenGL renderer string: Mesa DRI Radeon 20021009 AGP 2x x86/MMX/3DNow!/SSE TCL OpenGL version string: 1.2 Mesa 5.0 colordepth: 24bpp # rgba_coming.zip: (64k-demo) ftp://ftp.scene.org/pub/parties/2002/bcnparty10/in64/ wine: perfect: no fixmes/warnings/errors DRI: default: if these quads are intendet: perfect ... someone should try it out on a different system RADEON_TCL_FORCE_DISABLE=1: rendering errors: missing triangles/quads/strips RADEON_NO_VTXFMT=1: like default # petroleo_boah.zip: (demo, 5,9M) ftp://ftp.scene.org/pub/parties/2002/bcnparty10/demo/ wine: good: some fixmes:system:ChangeDisplaySettingsA :dsound... DRI: default: rendering errors: artifacts, texturing errors RADEON_TCL_FORCE_DISABLE=1: looks perfect RADEON_NO_VTXFMT=1: looks perfect RADEON_NO_CODEGEN=1: like default # best regards, Andreas --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Weekly dri-devel meeting reminder
This is just a friendly reminder that the weeking dri-devel IRC meeting will be starting in the #dri-devel channel on irc.openprojects.net at 2100 UTC (or 4:00PM EST or 1:00PST, if you prefer). Time zone conversion available at: http://www.timezoneconverter.com/cgi-bin/tzc.tzc --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] dri-devel, You have to check this out! Gen*ric V*agra only $5.00 per 100MG dose
Title: mfldetnawivpvqibpbxkfkpnupdm
Dear dri-devel Generic Viagra Value Drugstore Tired Of Paying Too Much For Viagra?For the first time ever a generic equivalent to Viagra® is available. Generic Sildenafil Citrate (GSC-100) and Viagra® both consist of 100 mg of sildenafil citrate. GSC-100 is simply a generic version of Viagra® - just like ibuprofen is the generic name for Advil®. Limited Time Offer: 15 pills for $119.00 CLICK HERE TO $AVE NOW! Why pay twice as much when GSC-100 is the same thing and is only a click away?mfldetnawivpvqibpbxkfkpnupdmCopyright © 2002 Generic Viagra. All rights reserved. 100% Money Back Guarantee - The First Pharmaceutical to ever be guaranteedViagra® is a trademark of the Pfizer, Inc. and is not affiliated with Generic Viagra. To be taken off our database. Please click below. Your email address to be immediately removed. áË ë^¨¥Ë)¢{(ç[É8bAzEÊ&zÚ yé!y«Þm§ÿí)äç¤r¿±ðëׯzYX§X¬´:âuëÞX¬¶Ë(º· ~àzwÛi³ÿåËl²«qç讧zßåËlþX¬¶)ߣ÷kׯz
[Dri-devel] Direct Rendering Enabled / Indirect Rendering Used
I finally got a momment this weekend to build the CVS tree since I had not done it since 11/22. My usual build procedure is that I take the regular XFree86 CVS tree and merge in the DRI stuff ... the merge is fairly straight forward as only certain directories really get touched in the DRI tree (I sure wish a better way could be found then keeping two trees active like this ...). The build went fine and when I loaded up X it proceded to tell me that direct rendering was enabled. However - glxinfo reports that indirect rendering is being used. This started for me after that last large Mesa merge into the trunk at the end of November. Did I miss something on this list that I have to do something special? Attached is my log file for XFree86 for the curious and my glxinfo is pasted below. [dhageman@moko dhageman]$ glxinfo name of display: :0.0 display: :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 extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context OpenGL vendor string: Mesa project: www.mesa3d.org OpenGL renderer string: Mesa GLX Indirect OpenGL version string: 1.4 Mesa 5.0 OpenGL extensions: GL_ARB_depth_texture, GL_ARB_imaging, GL_ARB_multitexture, GL_ARB_point_parameters, GL_ARB_shadow, GL_ARB_shadow_ambient, GL_ARB_texture_border_clamp, GL_ARB_texture_cube_map, GL_ARB_texture_env_add, GL_ARB_texture_env_combine, GL_ARB_texture_env_crossbar, GL_ARB_texture_env_dot3, GL_ARB_texture_mirrored_repeat, GL_ARB_transpose_matrix, GL_ARB_window_pos, GL_EXT_abgr, GL_EXT_blend_color, GL_EXT_blend_minmax, GL_EXT_blend_subtract, GL_EXT_stencil_two_side, GL_EXT_texture_env_add, GL_EXT_texture_env_combine, GL_EXT_texture_env_dot3, GL_EXT_texture_lod_bias glu version: 1.3 glu extensions: GLU_EXT_nurbs_tessellator, GLU_EXT_object_space_tess visual x bf lv rg d st colorbuffer ax dp st accumbuffer ms cav id dep cl sp sz l ci b ro r g b a bf th cl r g b a ns b eat -- 0x23 16 tc 0 16 0 r y . 5 6 5 0 0 16 0 0 0 0 0 0 0 None 0x24 16 tc 0 16 0 r y . 5 6 5 0 0 16 8 0 0 0 0 0 0 None 0x25 16 tc 0 16 0 r y . 5 6 5 0 0 16 0 16 16 16 0 0 0 Slow 0x26 16 tc 0 16 0 r y . 5 6 5 0 0 16 8 16 16 16 0 0 0 Slow 0x27 16 dc 0 16 0 r y . 5 6 5 0 0 16 0 0 0 0 0 0 0 None 0x28 16 dc 0 16 0 r y . 5 6 5 0 0 16 8 0 0 0 0 0 0 None 0x29 16 dc 0 16 0 r y . 5 6 5 0 0 16 0 16 16 16 0 0 0 Slow 0x2a 16 dc 0 16 0 r y . 5 6 5 0 0 16 8 16 16 16 0 0 0 Slow -- //\\ || D. Hageman<[EMAIL PROTECTED]> || \\// This is a pre-release version of XFree86, and is not supported in any way. Bugs may be reported to [EMAIL PROTECTED] and patches submitted to [EMAIL PROTECTED] Before reporting bugs in pre-release versions, please check the latest version in the XFree86 CVS repository (http://www.XFree86.Org/cvs) XFree86 Version 4.2.99.2 (Custom Build: 4.2.99.2-20021209) / X Window System (protocol Version 11, revision 0, vendor release 6600) Release Date: 25 November 2002 If the server is older than 6-12 months, or if your card is newer than the above date, look for a newer version before reporting problems. (See http://www.XFree86.Org/) Build Operating System: Linux 2.4.18-18 i686 [ELF] Build Host: moko.dracken.com Module Loader present OS Kernel: Linux version 2.4.18-18 ([EMAIL PROTECTED]) (gcc version 3.2 20020903 (Red Hat Linux 8.0 3.2-7)) #1 Mon Nov 4 10:05:37 CST 2002 Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/var/log/XFree86.0.log", Time: Mon Dec 9 10:32:21 2002 (==) Using config file: "/etc/X11/XF86Config" (==) ServerLayout "D. Hageman Configured" (**) |-->Screen "Screen0" (0) (**) | |-->Monitor "Monitor0" (**) | |-->Device "Card0" (**) |-->Input Device "Mouse0" (**) |-->Input Device "Keyboard0" (**) Option "XkbRules" "xfree86" (**) XKB: rules: "xfree86" (**) Option "XkbModel" "pc105" (**) XKB: model: "pc105" (**) Option "XkbLayout" "us" (**) XKB: layout: "us" (==) Keyboard: CustomKeycode disabled (WW) `font
