Re: Current redhat xorg-x11-Mesa-libGL-6.7.0-2.i386.rpm
On Tuesday 18 May 2004 22:34, Jon Smirl wrote: DRI is definitely working in this build, glxgears is 152FPS on a Rage128. But when I do glxinfo it reports the software driver: OpenGL renderer string: Mesa GLX Indirect How fast is the CPU? I've seen 200FPS in glxgears in software with a 2GHz P4. Or did someone fix the software render? I used to get about 3FPS with it. Maybe something is broken in the DRI into xorg server integration? From your second post it looks like the same issue as http://marc.theaimsgroup.com/?l=dri-usersm=108328244131329w=2 . Run ldd on glxgears and see where it's getting libGL from. I'm pulling down the SRPM now, I'll take a look in the morning. Hopefully the patch will jump out at me. If this is Jakub's patch causing problems I'd like to come up with a solution that preserves binary compatibility, since I'd like to see that patch (or something like it) integrated. - ajax --- This SF.Net email is sponsored by: SourceForge.net Broadband Sign-up now for SourceForge Broadband and get the fastest 6.0/768 connection for only $19.95/mo for the first 3 months! http://ads.osdn.com/?ad_id%62alloc_ida84op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] Re: [Dri-devel] Memory management of AGP and VRAM
Jon Smirl wrote: --- Alan Cox [EMAIL PROTECTED] wrote: On Maw, 2004-05-18 at 21:14, Jon Smirl wrote: So you don't have any problem with pulling VT support out of the kernel? You need the code to handle video context switches. You also need vt's because you have multiple security contexts on the PC console and good reason to keep that when using SELinux. VT switch is easy however. DRI+X already handles that, and we never have two people using the VT at once. Its one device, multiple handles only one currently active - like many other drivers Why does VT switch have to be in the kernel? I can have multiple xterms logged in as different users without kernel support. Why can't VT switching be implemented as if I was switching between multiple fullscreen xterms? I guess I don't see why there is a difference between multiple xterms and VT's. I can use su to set the xterm to any account. what if you want to create a 'freshclean' console using the SAK key or if your primary terminal is not responsive anymore? You need to be able to create a new terminal without any help of the currently active console and you need to be able to restart the graphics helper library/server/whatever at any time without killing your running applications on other 'VTs'. Holger --- This SF.Net email is sponsored by: SourceForge.net Broadband Sign-up now for SourceForge Broadband and get the fastest 6.0/768 connection for only $19.95/mo for the first 3 months! http://ads.osdn.com/?ad_id=2562alloc_id=6184op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: savage texture compression - good news
Mark Cass wrote: guys, finally have some good news. uploading DXT1, DXT3, and DXT5 compressed textures is working. i still need to implement compressed sub textures and test very small textures. the issue was the tile size. i wrote an iterator into the driver to test all possible tile sizes and found the one that worked. well, actually two that worked. DXT1 has a different tile format than DXT3 and DXT5 which share the same format. Nice to hear it works. my next question involves extensions. should the GL_ARB_texture_compression and GL_EXT_texture_compression_s3tc extensions be enabled? the only reason i ask is that i think the complete description of the extension includes the ability for the driver to compress the textures. as was mentioned previously, adding this ability to the driver could result in legal problems as s3tc is intellectual property of S3/VIA inc. Ian has already answered the part about GL_ARB_texture_compression. GL_EXT_texture_compression_s3tc is a problem. You're not supposed to enable it if you can't guarantee that you can always handle the associated s3tc texture formats - and you can't guarantee that without software compression/decompression. But if you're not announcing it, nobody will use the dxt formats (even for precompressed textures) you just made to work (nwn and others will check if the extension is present). You could do what I did, don't enable the extension if software decompression/compression is unavailable per default, but make it possible to enable it via driconf. btw it's kinda ironic the extension can't be fully implemented - after all, we're talking about a Savage chip here! Just the other day, I had some strange idea how to write a s3tc compressor which would be legally unproblematic. I _think_ the format itself cannot be patented, only the compression apparatus (which is, btw, just math, but that's not the point here). So, use straight BTC[1] (block truncation coding)/CCC[2] (color cell compression) (there are plenty of references to these papers on the web) to compress! This works because s3tc is an improved btc/ccc, your textures would be correctly decompressionable by any s3tc decompressor. RGB_DXT1: use CCC. Instead of two base colors and two (or one, depending on the ordering of the colors) derived colors, only use the two base colors. That's all. Of course, quality would be much lower, only 1 bit of the 2 bit index is used. RGB_DXT3: same as RGB_DXT1 for the color part. Alpha part is no problem (just uncompressed 4bit alpha anyway). RGB_DXT5. same as RGB_DXT1 for the color part. For alpha, use BTC (instead of 2 base values and 6 derived (or 4 derived and two fixed values, depending on the ordering of the two base values) only use the two base values. Not good quality (only 1 bit of the 3 bit index is used). RGBA_DXT1: problematic (not straight CCC). Probably non-infringing implementation would just use only one color, the second color would be used for the transparent case. So all pixels (safe the transparent ones) would end up with the same color within a block... Software decompresion though is a problem, if that's also covered by the patent. Using CCC/BTC would lead to errors, which could be very significant (unless you have compressed according to the above mentioned scheme, of course). In fact, in some cases the results could be completely wrong (for RGBA_DXT1, and RGBA_DXT5 at least, due to the different interpretation needed based on the ordering of the base values, which BTC/CCC decompressor would simply ignore). Roland [1] Image Compression Using Block Truncation Coding, Delp/Mitchell, IEEE Transactions on Communications 27: (9), 1979, pages 1335-1342 [2] Two Bit/Pixel Full Color Encoding, Campbell et al., SIGGRAPH 86 Conference Proceedings, Computer Graphics, Vol. 20, No. 4, August 1986, pages 215-223 --- This SF.Net email is sponsored by: SourceForge.net Broadband Sign-up now for SourceForge Broadband and get the fastest 6.0/768 connection for only $19.95/mo for the first 3 months! http://ads.osdn.com/?ad_id%62alloc_ida84op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: savage texture compression - good news
FYI, relevant patents numbers are: 5,956,431 6,658,146 See more info here: http://marc.theaimsgroup.com/?l=dri-develm=107704096508208w=2 --- Roland Scheidegger [EMAIL PROTECTED] wrote: Mark Cass wrote: guys, finally have some good news. uploading DXT1, DXT3, and DXT5 compressed textures is working. i still need to implement compressed sub textures and test very small textures. the issue was the tile size. i wrote an iterator into the driver to test all possible tile sizes and found the one that worked. well, actually two that worked. DXT1 has a different tile format than DXT3 and DXT5 which share the same format. Nice to hear it works. my next question involves extensions. should the GL_ARB_texture_compression and GL_EXT_texture_compression_s3tc extensions be enabled? the only reason i ask is that i think the complete description of the extension includes the ability for the driver to compress the textures. as was mentioned previously, adding this ability to the driver could result in legal problems as s3tc is intellectual property of S3/VIA inc. Ian has already answered the part about GL_ARB_texture_compression. GL_EXT_texture_compression_s3tc is a problem. You're not supposed to enable it if you can't guarantee that you can always handle the associated s3tc texture formats - and you can't guarantee that without software compression/decompression. But if you're not announcing it, nobody will use the dxt formats (even for precompressed textures) you just made to work (nwn and others will check if the extension is present). You could do what I did, don't enable the extension if software decompression/compression is unavailable per default, but make it possible to enable it via driconf. btw it's kinda ironic the extension can't be fully implemented - after all, we're talking about a Savage chip here! Just the other day, I had some strange idea how to write a s3tc compressor which would be legally unproblematic. I _think_ the format itself cannot be patented, only the compression apparatus (which is, btw, just math, but that's not the point here). So, use straight BTC[1] (block truncation coding)/CCC[2] (color cell compression) (there are plenty of references to these papers on the web) to compress! This works because s3tc is an improved btc/ccc, your textures would be correctly decompressionable by any s3tc decompressor. RGB_DXT1: use CCC. Instead of two base colors and two (or one, depending on the ordering of the colors) derived colors, only use the two base colors. That's all. Of course, quality would be much lower, only 1 bit of the 2 bit index is used. RGB_DXT3: same as RGB_DXT1 for the color part. Alpha part is no problem (just uncompressed 4bit alpha anyway). RGB_DXT5. same as RGB_DXT1 for the color part. For alpha, use BTC (instead of 2 base values and 6 derived (or 4 derived and two fixed values, depending on the ordering of the two base values) only use the two base values. Not good quality (only 1 bit of the 3 bit index is used). RGBA_DXT1: problematic (not straight CCC). Probably non-infringing implementation would just use only one color, the second color would be used for the transparent case. So all pixels (safe the transparent ones) would end up with the same color within a block... Software decompresion though is a problem, if that's also covered by the patent. Using CCC/BTC would lead to errors, which could be very significant (unless you have compressed according to the above mentioned scheme, of course). In fact, in some cases the results could be completely wrong (for RGBA_DXT1, and RGBA_DXT5 at least, due to the different interpretation needed based on the ordering of the base values, which BTC/CCC decompressor would simply ignore). Roland [1] Image Compression Using Block Truncation Coding, Delp/Mitchell, IEEE Transactions on Communications 27: (9), 1979, pages 1335-1342 [2] Two Bit/Pixel Full Color Encoding, Campbell et al., SIGGRAPH 86 Conference Proceedings, Computer Graphics, Vol. 20, No. 4, August 1986, pages 215-223 __ Do you Yahoo!? SBC Yahoo! - Internet access at a great low price. http://promo.yahoo.com/sbc/ --- This SF.Net email is sponsored by: SourceForge.net Broadband Sign-up now for SourceForge Broadband and get the fastest 6.0/768 connection for only $19.95/mo for the first 3 months! http://ads.osdn.com/?ad_id=2562alloc_id=6184op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Current redhat xorg-x11-Mesa-libGL-6.7.0-2.i386.rpm
--- Adam Jackson [EMAIL PROTECTED] wrote: From your second post it looks like the same issue as http://marc.theaimsgroup.com/?l=dri-usersm=108328244131329w=2 . Run ldd on glxgears and see where it's getting libGL from. I'm pulling down the SRPM now, I'll take a look in the morning. Hopefully the patch will jump out at me. If this is Jakub's patch causing problems I'd like to come up with a solution that preserves binary compatibility, since I'd like to see that patch (or something like it) integrated. [EMAIL PROTECTED] jonsmirl]$ which glxgears /usr/X11R6/bin/glxgears [EMAIL PROTECTED] jonsmirl]$ ldd /usr/X11R6/bin/glxgears linux-gate.so.1 = (0xe000) libGL.so.1 = /usr/X11R6/lib/tls/libGL.so.1 (0x465c8000) libXext.so.6 = /usr/X11R6/lib/libXext.so.6 (0x40001000) libX11.so.6 = /usr/X11R6/lib/libX11.so.6 (0x4000f000) libpthread.so.0 = /lib/tls/libpthread.so.0 (0x459d8000) libm.so.6 = /lib/tls/libm.so.6 (0x458c) libc.so.6 = /lib/tls/libc.so.6 (0x457a3000) libdl.so.2 = /lib/libdl.so.2 (0x458e5000) /lib/ld-linux.so.2 = /lib/ld-linux.so.2 (0x4578a000) [EMAIL PROTECTED] jonsmirl]$ export LIBGL_DEBUG=1 [EMAIL PROTECTED] jonsmirl]$ glxgears libGL error: dlopen /usr/X11R6/lib/modules/dri/r128_dri.so failed (/usr/X11R6/lib/modules/dri/r128_dri.so: undefined symbol: _glapi_Dispatch) libGL error: unable to find driver: r128_dri.so libGL error: dlopen /usr/X11R6/lib/modules/dri/r128_dri.so failed (/usr/X11R6/lib/modules/dri/r128_dri.so: undefined symbol: _glapi_Dispatch) libGL error: unable to find driver: r128_dri.so 771 frames in 5.0 seconds = 154.200 FPS XIO: fatal IO error 104 (Connection reset by peer) on X server :0.0 after 3258 requests (33 known processed) with 0 events remaining. [EMAIL PROTECTED] jonsmirl]$ [EMAIL PROTECTED] jonsmirl]$ ls /var/cache/yum/development/packages/xorg* /var/cache/yum/development/packages/xorg-x11-100dpi-fonts-6.7.0-2.i386.rpm /var/cache/yum/development/packages/xorg-x11-6.7.0-2.i386.rpm /var/cache/yum/development/packages/xorg-x11-75dpi-fonts-6.7.0-2.i386.rpm /var/cache/yum/development/packages/xorg-x11-base-fonts-6.7.0-2.i386.rpm /var/cache/yum/development/packages/xorg-x11-devel-6.7.0-2.i386.rpm /var/cache/yum/development/packages/xorg-x11-doc-6.7.0-2.i386.rpm /var/cache/yum/development/packages/xorg-x11-font-utils-6.7.0-2.i386.rpm /var/cache/yum/development/packages/xorg-x11-libs-6.7.0-2.i386.rpm /var/cache/yum/development/packages/xorg-x11-libs-data-6.7.0-2.i386.rpm /var/cache/yum/development/packages/xorg-x11-Mesa-libGL-6.7.0-2.i386.rpm /var/cache/yum/development/packages/xorg-x11-Mesa-libGLU-6.7.0-2.i386.rpm /var/cache/yum/development/packages/xorg-x11-tools-6.7.0-2.i386.rpm /var/cache/yum/development/packages/xorg-x11-truetype-fonts-6.7.0-2.i386.rpm /var/cache/yum/development/packages/xorg-x11-twm-6.7.0-2.i386.rpm /var/cache/yum/development/packages/xorg-x11-xauth-6.7.0-2.i386.rpm /var/cache/yum/development/packages/xorg-x11-xdm-6.7.0-2.i386.rpm /var/cache/yum/development/packages/xorg-x11-xfs-6.7.0-2.i386.rpm /var/cache/yum/development/packages/xorg-x11-Xnest-6.7.0-2.i386.rpm /var/cache/yum/development/packages/xorg-x11-Xvfb-6.7.0-2.i386.rpm [EMAIL PROTECTED] jonsmirl]$ = Jon Smirl [EMAIL PROTECTED] __ Do you Yahoo!? SBC Yahoo! - Internet access at a great low price. http://promo.yahoo.com/sbc/ --- This SF.Net email is sponsored by: SourceForge.net Broadband Sign-up now for SourceForge Broadband and get the fastest 6.0/768 connection for only $19.95/mo for the first 3 months! http://ads.osdn.com/?ad_id=2562alloc_id=6184op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] Re: [Dri-devel] Memory management of AGP and VRAM
--- Holger Waechtler [EMAIL PROTECTED] wrote: Why does VT switch have to be in the kernel? I can have multiple xterms logged in as different users without kernel support. Why can't VT switching be implemented as if I was switching between multiple fullscreen xterms? I guess I don't see why there is a difference between multiple xterms and VT's. I can use su to set the xterm to any account. what if you want to create a 'freshclean' console using the SAK key or if your primary terminal is not responsive anymore? You need to be able to create a new terminal without any help of the currently active console and you need to be able to restart the graphics helper library/server/whatever at any time without killing your running applications on other 'VTs'. In this model SAK is implemented in the kernel by the system console. Hitting SAK will always work even if the terminal is not responsive (unless the kernel is dead). SAK will whack all apps on the user console, reload the graphics libs, and get you a fresh shell. In this model it is not possible to restart the graphics lib on one console without restarting all of the virtual consoles since they are all sharing the same process. This seems secure to me. Whacking everything with SAK and reloading the graphics libraries completely stops any attack that may try to load code into the graphics card. I wouldn't be surprised if you could write a pixel shader program that emulates a login screen. It may be possible to build this to suspend the apps instead of whacking them. Then you could reattached them if needed. If not reattached in a few minutes they would die. = Jon Smirl [EMAIL PROTECTED] __ Do you Yahoo!? SBC Yahoo! - Internet access at a great low price. http://promo.yahoo.com/sbc/ --- This SF.Net email is sponsored by: SourceForge.net Broadband Sign-up now for SourceForge Broadband and get the fastest 6.0/768 connection for only $19.95/mo for the first 3 months! http://ads.osdn.com/?ad_id=2562alloc_id=6184op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Current redhat xorg-x11-Mesa-libGL-6.7.0-2.i386.rpm
Getting rid of the copy in /usr/X11R6/lib/tls doesn't make a difference. --- Jon Smirl [EMAIL PROTECTED] wrote: --- Adam Jackson [EMAIL PROTECTED] wrote: From your second post it looks like the same issue as http://marc.theaimsgroup.com/?l=dri-usersm=108328244131329w=2 . Run ldd on glxgears and see where it's getting libGL from. I'm pulling down the SRPM now, I'll take a look in the morning. Hopefully the patch will jump out at me. If this is Jakub's patch causing problems I'd like to come up with a solution that preserves binary compatibility, since I'd like to see that patch (or something like it) integrated. [EMAIL PROTECTED] jonsmirl]$ which glxgears /usr/X11R6/bin/glxgears [EMAIL PROTECTED] jonsmirl]$ ldd /usr/X11R6/bin/glxgears linux-gate.so.1 = (0xe000) libGL.so.1 = /usr/X11R6/lib/tls/libGL.so.1 (0x465c8000) libXext.so.6 = /usr/X11R6/lib/libXext.so.6 (0x40001000) libX11.so.6 = /usr/X11R6/lib/libX11.so.6 (0x4000f000) libpthread.so.0 = /lib/tls/libpthread.so.0 (0x459d8000) libm.so.6 = /lib/tls/libm.so.6 (0x458c) libc.so.6 = /lib/tls/libc.so.6 (0x457a3000) libdl.so.2 = /lib/libdl.so.2 (0x458e5000) /lib/ld-linux.so.2 = /lib/ld-linux.so.2 (0x4578a000) [EMAIL PROTECTED] jonsmirl]$ export LIBGL_DEBUG=1 [EMAIL PROTECTED] jonsmirl]$ glxgears libGL error: dlopen /usr/X11R6/lib/modules/dri/r128_dri.so failed (/usr/X11R6/lib/modules/dri/r128_dri.so: undefined symbol: _glapi_Dispatch) libGL error: unable to find driver: r128_dri.so libGL error: dlopen /usr/X11R6/lib/modules/dri/r128_dri.so failed (/usr/X11R6/lib/modules/dri/r128_dri.so: undefined symbol: _glapi_Dispatch) libGL error: unable to find driver: r128_dri.so 771 frames in 5.0 seconds = 154.200 FPS XIO: fatal IO error 104 (Connection reset by peer) on X server :0.0 after 3258 requests (33 known processed) with 0 events remaining. [EMAIL PROTECTED] jonsmirl]$ [EMAIL PROTECTED] jonsmirl]$ ls /var/cache/yum/development/packages/xorg* /var/cache/yum/development/packages/xorg-x11-100dpi-fonts-6.7.0-2.i386.rpm /var/cache/yum/development/packages/xorg-x11-6.7.0-2.i386.rpm /var/cache/yum/development/packages/xorg-x11-75dpi-fonts-6.7.0-2.i386.rpm /var/cache/yum/development/packages/xorg-x11-base-fonts-6.7.0-2.i386.rpm /var/cache/yum/development/packages/xorg-x11-devel-6.7.0-2.i386.rpm /var/cache/yum/development/packages/xorg-x11-doc-6.7.0-2.i386.rpm /var/cache/yum/development/packages/xorg-x11-font-utils-6.7.0-2.i386.rpm /var/cache/yum/development/packages/xorg-x11-libs-6.7.0-2.i386.rpm /var/cache/yum/development/packages/xorg-x11-libs-data-6.7.0-2.i386.rpm /var/cache/yum/development/packages/xorg-x11-Mesa-libGL-6.7.0-2.i386.rpm /var/cache/yum/development/packages/xorg-x11-Mesa-libGLU-6.7.0-2.i386.rpm /var/cache/yum/development/packages/xorg-x11-tools-6.7.0-2.i386.rpm /var/cache/yum/development/packages/xorg-x11-truetype-fonts-6.7.0-2.i386.rpm /var/cache/yum/development/packages/xorg-x11-twm-6.7.0-2.i386.rpm /var/cache/yum/development/packages/xorg-x11-xauth-6.7.0-2.i386.rpm /var/cache/yum/development/packages/xorg-x11-xdm-6.7.0-2.i386.rpm /var/cache/yum/development/packages/xorg-x11-xfs-6.7.0-2.i386.rpm /var/cache/yum/development/packages/xorg-x11-Xnest-6.7.0-2.i386.rpm /var/cache/yum/development/packages/xorg-x11-Xvfb-6.7.0-2.i386.rpm [EMAIL PROTECTED] jonsmirl]$ = Jon Smirl [EMAIL PROTECTED] __ Do you Yahoo!? SBC Yahoo! - Internet access at a great low price. http://promo.yahoo.com/sbc/ --- This SF.Net email is sponsored by: SourceForge.net Broadband Sign-up now for SourceForge Broadband and get the fastest 6.0/768 connection for only $19.95/mo for the first 3 months! http://ads.osdn.com/?ad_id=2562alloc_id=6184op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel = Jon Smirl [EMAIL PROTECTED] __ Do you Yahoo!? SBC Yahoo! - Internet access at a great low price. http://promo.yahoo.com/sbc/ --- This SF.Net email is sponsored by: SourceForge.net Broadband Sign-up now for SourceForge Broadband and get the fastest 6.0/768 connection for only $19.95/mo for the first 3 months! http://ads.osdn.com/?ad_id=2562alloc_id=6184op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Current redhat xorg-x11-Mesa-libGL-6.7.0-2.i386.rpm
--- Jon Smirl [EMAIL PROTECTED] wrote: --- Adam Jackson [EMAIL PROTECTED] wrote: From your second post it looks like the same issue as http://marc.theaimsgroup.com/?l=dri-usersm=108328244131329w=2 . Run ldd on glxgears and see where it's getting libGL from. I'm pulling down the SRPM now, I'll take a look in the morning. Hopefully the patch will jump out at me. If this is Jakub's patch causing problems I'd like to come up with a solution that preserves binary compatibility, since I'd like to see that patch (or something like it) integrated. [EMAIL PROTECTED] jonsmirl]$ which glxgears /usr/X11R6/bin/glxgears [EMAIL PROTECTED] jonsmirl]$ ldd /usr/X11R6/bin/glxgears linux-gate.so.1 = (0xe000) libGL.so.1 = /usr/X11R6/lib/tls/libGL.so.1 (0x465c8000) it's using the tls version of libGL. I've never had much luck with the tls versions. If you built your own libGL or 3d driver, switch to those versions. mixing tls and non-tls never seems to work. Alex libXext.so.6 = /usr/X11R6/lib/libXext.so.6 (0x40001000) libX11.so.6 = /usr/X11R6/lib/libX11.so.6 (0x4000f000) libpthread.so.0 = /lib/tls/libpthread.so.0 (0x459d8000) libm.so.6 = /lib/tls/libm.so.6 (0x458c) libc.so.6 = /lib/tls/libc.so.6 (0x457a3000) libdl.so.2 = /lib/libdl.so.2 (0x458e5000) /lib/ld-linux.so.2 = /lib/ld-linux.so.2 (0x4578a000) [EMAIL PROTECTED] jonsmirl]$ export LIBGL_DEBUG=1 [EMAIL PROTECTED] jonsmirl]$ glxgears libGL error: dlopen /usr/X11R6/lib/modules/dri/r128_dri.so failed (/usr/X11R6/lib/modules/dri/r128_dri.so: undefined symbol: _glapi_Dispatch) libGL error: unable to find driver: r128_dri.so libGL error: dlopen /usr/X11R6/lib/modules/dri/r128_dri.so failed (/usr/X11R6/lib/modules/dri/r128_dri.so: undefined symbol: _glapi_Dispatch) libGL error: unable to find driver: r128_dri.so 771 frames in 5.0 seconds = 154.200 FPS XIO: fatal IO error 104 (Connection reset by peer) on X server :0.0 after 3258 requests (33 known processed) with 0 events remaining. [EMAIL PROTECTED] jonsmirl]$ [EMAIL PROTECTED] jonsmirl]$ ls /var/cache/yum/development/packages/xorg* /var/cache/yum/development/packages/xorg-x11-100dpi-fonts-6.7.0-2.i386.rpm /var/cache/yum/development/packages/xorg-x11-6.7.0-2.i386.rpm /var/cache/yum/development/packages/xorg-x11-75dpi-fonts-6.7.0-2.i386.rpm /var/cache/yum/development/packages/xorg-x11-base-fonts-6.7.0-2.i386.rpm /var/cache/yum/development/packages/xorg-x11-devel-6.7.0-2.i386.rpm /var/cache/yum/development/packages/xorg-x11-doc-6.7.0-2.i386.rpm /var/cache/yum/development/packages/xorg-x11-font-utils-6.7.0-2.i386.rpm /var/cache/yum/development/packages/xorg-x11-libs-6.7.0-2.i386.rpm /var/cache/yum/development/packages/xorg-x11-libs-data-6.7.0-2.i386.rpm /var/cache/yum/development/packages/xorg-x11-Mesa-libGL-6.7.0-2.i386.rpm /var/cache/yum/development/packages/xorg-x11-Mesa-libGLU-6.7.0-2.i386.rpm /var/cache/yum/development/packages/xorg-x11-tools-6.7.0-2.i386.rpm /var/cache/yum/development/packages/xorg-x11-truetype-fonts-6.7.0-2.i386.rpm /var/cache/yum/development/packages/xorg-x11-twm-6.7.0-2.i386.rpm /var/cache/yum/development/packages/xorg-x11-xauth-6.7.0-2.i386.rpm /var/cache/yum/development/packages/xorg-x11-xdm-6.7.0-2.i386.rpm /var/cache/yum/development/packages/xorg-x11-xfs-6.7.0-2.i386.rpm /var/cache/yum/development/packages/xorg-x11-Xnest-6.7.0-2.i386.rpm /var/cache/yum/development/packages/xorg-x11-Xvfb-6.7.0-2.i386.rpm [EMAIL PROTECTED] jonsmirl]$ = Jon Smirl [EMAIL PROTECTED] __ Do you Yahoo!? SBC Yahoo! - Internet access at a great low price. http://promo.yahoo.com/sbc/ --- This SF.Net email is sponsored by: SourceForge.net Broadband Sign-up now for SourceForge Broadband and get the fastest 6.0/768 connection for only $19.95/mo for the first 3 months! http://ads.osdn.com/?ad_id=2562alloc_id=6184op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Current redhat xorg-x11-Mesa-libGL-6.7.0-2.i386.rpm
--- Alex Deucher [EMAIL PROTECTED] wrote: --- Jon Smirl [EMAIL PROTECTED] wrote: --- Adam Jackson [EMAIL PROTECTED] wrote: From your second post it looks like the same issue as http://marc.theaimsgroup.com/?l=dri-usersm=108328244131329w=2 . Run ldd on glxgears and see where it's getting libGL from. I'm pulling down the SRPM now, I'll take a look in the morning. Hopefully the patch will jump out at me. If this is Jakub's patch causing problems I'd like to come up with a solution that preserves binary compatibility, since I'd like to see that patch (or something like it) integrated. [EMAIL PROTECTED] jonsmirl]$ which glxgears /usr/X11R6/bin/glxgears [EMAIL PROTECTED] jonsmirl]$ ldd /usr/X11R6/bin/glxgears linux-gate.so.1 = (0xe000) libGL.so.1 = /usr/X11R6/lib/tls/libGL.so.1 (0x465c8000) it's using the tls version of libGL. I've never had much luck with the tls versions. If you built your own libGL or 3d driver, switch to those versions. mixing tls and non-tls never seems to work. Everything is intended to be stock from the redhat RPMs. I don't think I am mixing in anything I built. = Jon Smirl [EMAIL PROTECTED] __ Do you Yahoo!? SBC Yahoo! - Internet access at a great low price. http://promo.yahoo.com/sbc/ --- This SF.Net email is sponsored by: SourceForge.net Broadband Sign-up now for SourceForge Broadband and get the fastest 6.0/768 connection for only $19.95/mo for the first 3 months! http://ads.osdn.com/?ad_id=2562alloc_id=6184op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] Re: [Dri-devel] Memory management of AGP and VRAM
--- Holger Waechtler [EMAIL PROTECTED] wrote: hmmm, it's not clear to me how this concept would allow real multiple user logins at the same time like it is common -- you can rum multiple X11 instances on multiple VTs and every new user is able to hit SAK without killing other user's applications. Each user's device driver knows how to put up the SAK login screen on it's head. The SAK is only going to kill thing assoicated with that head. This works because each card's driver is required to support the system console at the kernel level. SAK will always be available from any head. We will need a kernel option to control whether the rest of the system console (pintk, kdbg, etc) is available from any head or just the boot device. Ctrl-Alt-Del has to be the SAK key. It will reset the graphics and start a new login process. SysReq will get you the system console. System console will show printk, kdbg, OOPs, etc. Both of these keys will be active even if X is running. You can toggle between system console and user console. But system console is not a shell, no one is logged in on it. It can only be used to run dedicated things like kdbg. Holger = Jon Smirl [EMAIL PROTECTED] __ Do you Yahoo!? SBC Yahoo! - Internet access at a great low price. http://promo.yahoo.com/sbc/ --- This SF.Net email is sponsored by: SourceForge.net Broadband Sign-up now for SourceForge Broadband and get the fastest 6.0/768 connection for only $19.95/mo for the first 3 months! http://ads.osdn.com/?ad_id=2562alloc_id=6184op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] Re: [Dri-devel] Memory management of AGP and VRAM
Jon Smirl wrote: --- Alan Cox [EMAIL PROTECTED] wrote: s/OpenGL/Some drawing library/ - providing its using the kernel interfaces we don't care what. (eg the bogl console driver is very small, the opengl one would probably be rather larger and nicer) I wasn't thinking that the kernel interface was standardized. For example DRM has some common IOCTLs and then hundreds of per chipset ones. There is no standard bitblt or draw char IOCTL. IMO, this is a long standing problem with the DRM. The main issue is that there's only one version number associated with each DRM module. What's needed is a device independent version and a device dependent version. In a sense, it needs something like an extension mechanism. Right now, some drivers support a vblank wait ioctl and some don't. The ones that do support it, support it the same way. If we could extend the DRM API in a device independent manner, we could solve some of this. When I thought about this in the past, I came up with two ways to do it. 1. Add a device independent version. Device independent code could be written that would test the version number the same way device dependent code does today. The drawback is that in order to advertise version X.N functionality, you also have to adverteise version [1.1, 1.N-1] functionality. Some hardware / drivers may not want to / be able to do that. 2. Add an extension query ioctl. Give each piece of functionality (i.e., all the related vblank functions) a unique number. Drivers would make a query like, Is extension 5 supported? If that ioctl returns true, then the driver could use that functionality. The disadvantage of this method is that it increases the number of ioctl calls that need to be made. Since the set of supported extensions can be tracked in the DRM with a bit string, the additional code size should be trivial. Thoughts? --- This SF.Net email is sponsored by: SourceForge.net Broadband Sign-up now for SourceForge Broadband and get the fastest 6.0/768 connection for only $19.95/mo for the first 3 months! http://ads.osdn.com/?ad_id=2562alloc_id=6184op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] Re: [Dri-devel] Memory management of AGP and VRAM
--- Ian Romanick [EMAIL PROTECTED] wrote: IMO, this is a long standing problem with the DRM. The main issue is that there's only one version number associated with each DRM module. What's needed is a device independent version and a device dependent version. In a sense, it needs something like an extension mechanism. Right now, some drivers support a vblank wait ioctl and some don't. The ones that do support it, support it the same way. The are two OpenGL implementations to consider, the DRI/mesa one and other vendor's. My thought was that DRM is an internal interface for Mesa's use. This means that ATI/Nvidia's stacks don't have to provide a DRM interface if they don't want to. DRM would not be a published API for general use. The only standard way to access the video hardware will be via an OpenGL library and only one library at a time can be used on single piece of hardware. If you accept that DRM is not a published API for general use, then we can do anything with want with the DRM interface. I'm all for anything that will make the code simpler to write. Nobody but a Mesa developer is ever going to use the interface. = Jon Smirl [EMAIL PROTECTED] __ Do you Yahoo!? SBC Yahoo! - Internet access at a great low price. http://promo.yahoo.com/sbc/ --- This SF.Net email is sponsored by: SourceForge.net Broadband Sign-up now for SourceForge Broadband and get the fastest 6.0/768 connection for only $19.95/mo for the first 3 months! http://ads.osdn.com/?ad_id=2562alloc_id=6184op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] Re: [Dri-devel] Memory management of AGP and VRAM
On Mer, 2004-05-19 at 01:35, Jon Smirl wrote: Why does VT switch have to be in the kernel? I can have multiple xterms logged in as different users without kernel support. Why can't VT switching be implemented as if I was switching between multiple fullscreen xterms? I guess I don't see why there is a difference between multiple xterms and VT's. I can use su to set the xterm to any account. You trust the X server. Thats already problematic with SELinux and compartmentalisation. For some things you need multiple X-servers for this reason. User space console makes it easier to go multi-user. Stick four cards in, run a user space console on each of them, and you have a four user system. No need for kernel support. Assuming you fix the input layer yes. I too would advocate that part being user space. We don't need multiple framebuffer let alone multiple keyboard/mouse mapping stuff in the kernel one, just what we have now or thereabouts --- This SF.Net email is sponsored by: SourceForge.net Broadband Sign-up now for SourceForge Broadband and get the fastest 6.0/768 connection for only $19.95/mo for the first 3 months! http://ads.osdn.com/?ad_id=2562alloc_id=6184op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] Re: [Dri-devel] Memory management of AGP and VRAM
On Maw, 2004-05-18 at 23:27, Keith Packard wrote: No thoughts to supporting multiple sets of VTs, one per physical device then? That would be nice but how much of that needs to be kernel side. Not a lot I suspect. --- This SF.Net email is sponsored by: SourceForge.net Broadband Sign-up now for SourceForge Broadband and get the fastest 6.0/768 connection for only $19.95/mo for the first 3 months! http://ads.osdn.com/?ad_id=2562alloc_id=6184op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] Re: [Dri-devel] Memory management of AGP and VRAM
--- Alan Cox [EMAIL PROTECTED] wrote: On Mer, 2004-05-19 at 01:35, Jon Smirl wrote: Why does VT switch have to be in the kernel? I can have multiple xterms logged in as different users without kernel support. Why can't VT switching be implemented as if I was switching between multiple fullscreen xterms? I guess I don't see why there is a difference between multiple xterms and VT's. I can use su to set the xterm to any account. You trust the X server. Thats already problematic with SELinux and compartmentalisation. For some things you need multiple X-servers for this reason. If we are going to build a new user space console, let's work with the SELinux people from the beginning to make it trustworthy. User space console could look just like the current VT system and run each session full screen. That stops the scraping the screen attack. xserver draws each app into it's own pbuffer. The individual apps don't have access to the main framebuffer. A properly designed xserver should be free from the screen scraping attack too. The DRM module will have to make sure you can't read buffers that don't belong to you. I don't want to go the model of running multiple X servers on the same hardware again. That path causes all of the problems with multitasking the device drivers on to the same piece of hardware. = Jon Smirl [EMAIL PROTECTED] __ Do you Yahoo!? SBC Yahoo! - Internet access at a great low price. http://promo.yahoo.com/sbc/ --- This SF.Net email is sponsored by: SourceForge.net Broadband Sign-up now for SourceForge Broadband and get the fastest 6.0/768 connection for only $19.95/mo for the first 3 months! http://ads.osdn.com/?ad_id=2562alloc_id=6184op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] Re: [Dri-devel] Memory management of AGP and VRAM
On Mer, 2004-05-19 at 20:30, Jon Smirl wrote: xserver draws each app into it's own pbuffer. The individual apps don't have access to the main framebuffer. A properly designed xserver should be free from the screen scraping attack too. The DRM module will have to make sure you can't read buffers that don't belong to you. X isnt trustable. You can't prove the needed trust. --- This SF.Net email is sponsored by: SourceForge.net Broadband Sign-up now for SourceForge Broadband and get the fastest 6.0/768 connection for only $19.95/mo for the first 3 months! http://ads.osdn.com/?ad_id=2562alloc_id=6184op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] Re: [Dri-devel] Memory management of AGP and VRAM
A rep from the SELinux group was at the Xdev conference. They are starting a project to verify X server. --- Alan Cox [EMAIL PROTECTED] wrote: On Mer, 2004-05-19 at 20:30, Jon Smirl wrote: xserver draws each app into it's own pbuffer. The individual apps don't have access to the main framebuffer. A properly designed xserver should be free from the screen scraping attack too. The DRM module will have to make sure you can't read buffers that don't belong to you. X isnt trustable. You can't prove the needed trust. --- This SF.Net email is sponsored by: SourceForge.net Broadband Sign-up now for SourceForge Broadband and get the fastest 6.0/768 connection for only $19.95/mo for the first 3 months! http://ads.osdn.com/?ad_id=2562alloc_id=6184op=click ___ Mesa3d-dev mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mesa3d-dev = Jon Smirl [EMAIL PROTECTED] __ Do you Yahoo!? SBC Yahoo! - Internet access at a great low price. http://promo.yahoo.com/sbc/ --- This SF.Net email is sponsored by: SourceForge.net Broadband Sign-up now for SourceForge Broadband and get the fastest 6.0/768 connection for only $19.95/mo for the first 3 months! http://ads.osdn.com/?ad_id=2562alloc_id=6184op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] Re: [Dri-devel] Memory management of AGP and VRAM
On Wed, 2004-05-19 at 11:25, Ian Romanick wrote: Jon Smirl wrote: --- Alan Cox [EMAIL PROTECTED] wrote: s/OpenGL/Some drawing library/ - providing its using the kernel interfaces we don't care what. (eg the bogl console driver is very small, the opengl one would probably be rather larger and nicer) I wasn't thinking that the kernel interface was standardized. For example DRM has some common IOCTLs and then hundreds of per chipset ones. There is no standard bitblt or draw char IOCTL. IMO, this is a long standing problem with the DRM. The main issue is that there's only one version number associated with each DRM module. What's needed is a device independent version and a device dependent version. In a sense, it needs something like an extension mechanism. Right now, some drivers support a vblank wait ioctl and some don't. The ones that do support it, support it the same way. If we could extend the DRM API in a device independent manner, we could solve some of this. When I thought about this in the past, I came up with two ways to do it. 1. Add a device independent version. Device independent code could be written that would test the version number the same way device dependent code does today. The drawback is that in order to advertise version X.N functionality, you also have to adverteise version [1.1, 1.N-1] functionality. Some hardware / drivers may not want to / be able to do that. 2. Add an extension query ioctl. Give each piece of functionality (i.e., all the related vblank functions) a unique number. Drivers would make a query like, Is extension 5 supported? If that ioctl returns true, then the driver could use that functionality. The disadvantage of this method is that it increases the number of ioctl calls that need to be made. Since the set of supported extensions can be tracked in the DRM with a bit string, the additional code size should be trivial. Thoughts? We already have a device independent version. What I put in was that the X Server can request a DRM device-independent and device-dependent interface version. The DRM changes its behavior accordingly (busid handling was the first change). Returns EINVAL if unsuccessful, and returns the actual version numbers of the DRM DI/DD interface, either way. Request -1.-1 version to just get the version number of an interface without changing anything. This was part of working to allow removal of old DRM code/features, which I've been completey distracted from. -- Eric Anholt[EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] --- This SF.Net email is sponsored by: SourceForge.net Broadband Sign-up now for SourceForge Broadband and get the fastest 6.0/768 connection for only $19.95/mo for the first 3 months! http://ads.osdn.com/?ad_id=2562alloc_id=6184op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] Re: [Dri-devel] Memory management of AGP and VRAM
Jon Smirl wrote: --- Holger Waechtler [EMAIL PROTECTED] wrote: Why does VT switch have to be in the kernel? I can have multiple xterms logged in as different users without kernel support. Why can't VT switching be implemented as if I was switching between multiple fullscreen xterms? I guess I don't see why there is a difference between multiple xterms and VT's. I can use su to set the xterm to any account. what if you want to create a 'freshclean' console using the SAK key or if your primary terminal is not responsive anymore? You need to be able to create a new terminal without any help of the currently active console and you need to be able to restart the graphics helper library/server/whatever at any time without killing your running applications on other 'VTs'. In this model SAK is implemented in the kernel by the system console. Hitting SAK will always work even if the terminal is not responsive (unless the kernel is dead). SAK will whack all apps on the user console, reload the graphics libs, and get you a fresh shell. In this model it is not possible to restart the graphics lib on one console without restarting all of the virtual consoles since they are all sharing the same process. This seems secure to me. Whacking everything with SAK and reloading the graphics libraries completely stops any attack that may try to load code into the graphics card. I wouldn't be surprised if you could write a pixel shader program that emulates a login screen. It may be possible to build this to suspend the apps instead of whacking them. Then you could reattached them if needed. If not reattached in a few minutes they would die. hmmm, it's not clear to me how this concept would allow real multiple user logins at the same time like it is common -- you can rum multiple X11 instances on multiple VTs and every new user is able to hit SAK without killing other user's applications. Holger --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: What is the current canonical procedure for reporting dri bugs?
Chris Metzler wrote: Hi. I'm a bit confused about the favored procedure for reporting DRI bugs. The DRI User Guide, at Thank you for pointing out the inconsistency of our documentation. As it turns out, we're in the process of changing the bug repository we use (again). Adam Jackson is setting up a bugzilla for us at X.org. We had originally been using the SourceForge bug tracker, but most of the developers on the project really, really hate it, so it wasn't actively maintained. We then moved to the XFree86 bugzilla. However, the driver code has moved CVS trees, and we're moving DRI away from XFree86 (in the sense that it will work with XFree86 *and* without). Because of that, we're moving a second, and hopefully final, time. Until the X.org bugzilla is setup, either existing repository will work. If the bug is observed in a released version of XFree86, the XFree86 folks would probably like to see it in their bugzilla. Thanks. --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] Re: [Dri-devel] Memory management of AGP and VRAM
--- Holger Waechtler [EMAIL PROTECTED] wrote: hmmm, it's not clear to me how this concept would allow real multiple user logins at the same time like it is common -- you can rum multiple X11 instances on multiple VTs and every new user is able to hit SAK without killing other user's applications. It's not going to allow multiple login prompts on different VTs on the same head. If you have a two headed card you will be able to use SAK on each one independently. SAK will kill the processes associated with that head, not all of the heads. If you have two cards each with four head you will be able to run four people each independently running xserver and SAK. What you won't be able to do is VT switch to another login screen. These screens will work like xterms, you switch to one then use su to change identity. When you switch you will already be logged on. This is because the SAK screen assigned ownership of the graphics device to the user id that is logged on. That let's the graphics code run without the need to be a root process. = Jon Smirl [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Domains Claim yours for only $14.70/year http://smallbusiness.promotions.yahoo.com/offer --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
intel i865 chipset docs...
Hi, I've just gotten an i865 system are there any docs out there for programming the 3d end of this? Intels site for that chipset has no programmers reference beyond the datasheet which doesn't say muc about 3D stuff.. Are these docs available non-NDA? Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Current redhat xorg-x11-Mesa-libGL-6.7.0-2.i386.rpm
I got this working. Something is wrong in those rpm's when they overlaid the -0.5 versions. For example 0.5 has the tls subdir and -2 does not. I whacked my X11R6 tree and reinstalled from the -2 rpms and everything works. I didn't spend the time tracking things down but some files that needed to be deleted from -0.5 aren't getting deleted when -2 is installed. = Jon Smirl [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Domains Claim yours for only $14.70/year http://smallbusiness.promotions.yahoo.com/offer --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: intel i865 chipset docs...
--- Dave Airlie [EMAIL PROTECTED] wrote: Hi, I've just gotten an i865 system are there any docs out there for programming the 3d end of this? Intels site for that chipset has no programmers reference beyond the datasheet which doesn't say muc about 3D stuff.. Are these docs available non-NDA? As far as I know the only non-NDA docs are the ones for the i810/5. I suspect you are out of luck. You could try asking though. Alex Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person __ Do you Yahoo!? Yahoo! Domains Claim yours for only $14.70/year http://smallbusiness.promotions.yahoo.com/offer --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Assert in r200 driver
Any ideas about what this is? It is from the Redhat -2 xorg rpm's. All of these programs ran fine on SW mesa and R128 driver. [EMAIL PROTECTED] cairogears]$ ./cairogears -glx COMP cairogears: r200_cmdbuf.c:295: r200EmitBlit: Assertion `(src_offset 1023) == 0 ' failed. Aborted [EMAIL PROTECTED] cairogears]$ ./cairogears -glx TEXT 322 frames in 5.0 seconds = 64.400 FPS 323 frames in 5.0 seconds = 64.600 FPS Broken pipe [EMAIL PROTECTED] cairogears]$ ./cairogears -glx TEXT2 cairogears: r200_cmdbuf.c:295: r200EmitBlit: Assertion `(src_offset 1023) == 0 ' failed. Aborted [EMAIL PROTECTED] cairogears]$ ./cairogears -glx SHADOW cairogears: r200_cmdbuf.c:295: r200EmitBlit: Assertion `(src_offset 1023) == 0 ' failed. Aborted [EMAIL PROTECTED] cairogears]$ dmesg = Jon Smirl [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Domains Claim yours for only $14.70/year http://smallbusiness.promotions.yahoo.com/offer --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
What is the current canonical procedure for reporting dri bugs?
Hi. I'm a bit confused about the favored procedure for reporting DRI bugs. The DRI User Guide, at http://dri.sourceforge.net/doc/DRIuserguide.html is recommended by the DRI wiki as important reading before bringing up problems. The DRI User Guide, in turn, suggests the Sourceforge bug database for DRI, at http://sourceforge.net/tracker/?group_id=387atid=100387 as the appropriate venue for reporting DRI bugs. Apparently from what I can see, bugs posted there also generate an announcement forwarded to this mailing list. However, elsewhere on the wiki, it seems to be suggested that this procedure is deprecated. Under Development--BugZilla, it's indicated that DRI bugs be posted through bugs.xfree86.org (to then be manually forwarded on to the dri-devel mailing list if the bug seems relevant to dri), and that the Sourceforge bug tracker is somewhat out of duty for some time. This last point seems to be borne out by the fact that no bugs posted at Sourceforge have been assigned to someone since almost a year ago. And then, as a third voice, the Testing/Debugging page on the Wiki ignores both the Sourceforge bug tracker and the XF86 BugZilla, and suggests just posting the bugs directly to this mailing list. Obviously in all three cases, a bug report ends up in this mailing list. But I can imagine that the favored route is to post a bug through the Sourceforge bug tracker or the XF86 BugZilla, because of additional functionality they provide. Or maybe not. What's the favored path? Thanks, -c -- Chris Metzler [EMAIL PROTECTED] (remove snip-me. to email) As a child I understood how to give; I have forgotten this grace since I have become civilized. - Chief Luther Standing Bear pgpWTPJHvWtIG.pgp Description: PGP signature
DRM and latency..
It has been pointed out to me by Andrew and Fernando Pablo Lopez-Lezcano that we do a lot of sleeping in code that probably should reschedule rather than sleep,radeon_do_wait_for_idle being a prime example, this has a DRM_UDELAY(1), this messes up audio latencys, Now I'm not sure that wholesale replacing these with a conditional schedule is correct, but in most cases it looks like there should be no issues doing this, theses functions are all usually called from a process context, My main worry is what to do on BSD about this?, should I just define a DRM_SCHED( delay ) and on Linux do a schedule and do a delay on BSD until someone steps up to figure it out? The r128/mga and i810 also suffer from something like this .. Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
