Re: [Dri-devel] Re: [Dri-users] Radeon 8500 woes...
[...] Well, I managed to run the newest binary snapshots by installing the newest r200-snapshot (yesterday) and copying radeon_drv.o from 0924 into my XFree-dir. It works. I even have Xv. That leads me to another question: what exactly is in radeon_drv.o? It's the 2D-driver, the 3D-parts lie in r200_dri.so (or radeon_dri.so for r100) Bye, Adam. --- 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: [Dri-users] Radeon 8500 woes...
Adam Duck wrote: Joe == Joe Mackay [EMAIL PROTECTED] writes: Joe On Thu, 10 Oct 2002, Frank Van Damme wrote: www.student.kuleuven.ac.be/~m9917684/r200-20020920-linux.i386.tar.bz2 should work. Joe Brilliant... thanks, you're a star! Joe Working fairly well now, apart from Xv. Just have to wait until it's as Joe good as the NVidia driver ;-) Well, I managed to run the newest binary snapshots by installing the newest r200-snapshot (yesterday) and copying radeon_drv.o from 0924 into my XFree-dir. It works. I even have Xv. That leads me to another question: what exactly is in radeon_drv.o? That's the 2d driver. It also does some 3d initialization, including turning on interrupts. 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] Mesa 4.1 branch
I've tested the radeon, r200 and tdfx drivers and they seem OK. I can't test the i810, i830, r128, mga, etc drivers (either because I don't have the right hardware or mine's broke). Some of the other drivers (like sis, ffb, etc) aren't enabled in the build process and haven't been ported. I'm not sure what the status of those drivers is. I've got most of these. I'll have a test fest later on. If I'm lucky I can do Ian's changes at the same time. 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] driver feature table
New columns for gamma, ffb, mach64, virge, sis and trident. Great work! Looks really impressive (and makes me feel really proud that my chip is not the worst one:). A couple of easy questions: is it true that Mach64 feature list is final (sure I do not mean fallback). Also, 3 features are marked as SW - is it good to expose them? It's actually not my question (someone already asked here before). Probably we could make exposition of non-HW-supported features optional (through XF86Config param)? Really, why inform application about things which are going to be slow? Or SW implementation of ARB/EXT_texture_env_* is fast? Regards, Sergey --- 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] The R200 09202002 Nightly *does* work in RH 8 (but there's something strange goin' on)
Am Freitag, 11. Oktober 2002 10:32 schrieb Christopher L. Estep: -Original Message- From: Dieter Nützel [mailto:[EMAIL PROTECTED]] Sent: Thursday, October 10, 2002 11:53 PM [-] Here's the triumphant log attached as proof: [-] (II) RADEON(0): Acceleration enabled (II) RADEON(0): Using hardware cursor (scanline 1024) (II) RADEON(0): Largest offscreen area available: 1280 x 7165 (II) RADEON(0): X context handle = 0x0001 (II) RADEON(0): [drm] installed DRM signal handler (II) RADEON(0): [DRI] installation complete (II) RADEON(0): [drm] Added 32 65536 byte vertex/indirect buffers (II) RADEON(0): [drm] Mapped 32 vertex/indirect buffers (II) RADEON(0): Direct rendering enabled [-] Have you verified with an app (gears)? How fast was it? 1017 fps, which is not *software* by any means. That was with an *AGPMode* of 2. I'm kicking it north to 4 (this *is* an AGP 4X card and mobo) and seeing what's next. AGPMode shouldn't do much for this test. But 1017 fps looks like hardware. It would be much more useful if you let us know which hardware (yes, r200) but CPU, RAM do you have. Then 1017 fps didn't look so fast for a r200 card. Here I get ~2393 fps (AGPMode 4) on a 1280x1024x24 desktop. dual Athlon MP 1900+ (but Mesa is single threaded, you know) 1 GB DDR SDRAM 266, CL2 r200, Powered by ATI 2.5.41-ac2 Cheers, Dieter PS A little bit trimming of your posts would be helpful ;-) --- 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] driver feature table
I think I can fill in a few blanks for mach64: Card names: 3D Rage Pro All-in-Wonder Pro Xpert 98/LCD/XL/@Play/@Work 3D Rage LT Pro 3D Rage XL 3D Rage Mobility - No hardware stencil - No mipmapping - BLEND texture env is a software fallback - texture environments which modulate alpha (AtAf) are fallbacks or non-compliant (e.g. RGBA textures with MODULATE environment are non-compliant) Correction: The ARB/EXT_texture_env_[add,dot3,combine] extensions actually are _not_ exported by default. Setting DRI_MACH64_OGL13=1 however will export these extensions and a few others to get glxinfo to report OpenGL 1.3, with the extensions being software fallbacks or no-ops. Extensions which might be doable in hardware, but not currently implemented: - EXT_paletted_texture - not sure about this, but the hardware seems to support a 2K texture palette in RGB 565. - ARB_texture_compression - would need an extension to implement 4:1 VQ texture compression supported by the hardware. On 11 Oct 2002, Sergey V. Udaltsov wrote: New columns for gamma, ffb, mach64, virge, sis and trident. Great work! Looks really impressive (and makes me feel really proud that my chip is not the worst one:). A couple of easy questions: is it true that Mach64 feature list is final (sure I do not mean fallback). Also, 3 features are marked as SW - is it good to expose them? It's actually not my question (someone already asked here before). Probably we could make exposition of non-HW-supported features optional (through XF86Config param)? Really, why inform application about things which are going to be slow? Or SW implementation of ARB/EXT_texture_env_* is fast? Regards, Sergey --- 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 -- Leif Delgass http://www.retinalburn.net --- 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] driver feature table
A couple of additions I forgot: 2D XFree86 Driver: ati_drv.o + atimisc_drv.o - Fog is disabled if alpha blending is enabled. On Fri, 11 Oct 2002, Leif Delgass wrote: I think I can fill in a few blanks for mach64: Card names: 3D Rage Pro All-in-Wonder Pro Xpert 98/LCD/XL/@Play/@Work 3D Rage LT Pro 3D Rage XL 3D Rage Mobility - No hardware stencil - No mipmapping - BLEND texture env is a software fallback - texture environments which modulate alpha (AtAf) are fallbacks or non-compliant (e.g. RGBA textures with MODULATE environment are non-compliant) Correction: The ARB/EXT_texture_env_[add,dot3,combine] extensions actually are _not_ exported by default. Setting DRI_MACH64_OGL13=1 however will export these extensions and a few others to get glxinfo to report OpenGL 1.3, with the extensions being software fallbacks or no-ops. Extensions which might be doable in hardware, but not currently implemented: - EXT_paletted_texture - not sure about this, but the hardware seems to support a 2K texture palette in RGB 565. - ARB_texture_compression - would need an extension to implement 4:1 VQ texture compression supported by the hardware. -- Leif Delgass http://www.retinalburn.net --- 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] Mesa 4.1 branch
Brian Paul wrote: Brian Paul wrote: Brian Paul wrote: I've created a new DRI branch: mesa-4-1-branch I'm in the process of porting all the DRI drivers to the new Mesa 4.1 code. I'll be checking in changes soon, but don't expect anything to run or even compile. I'll post again when I think it's usable. OK, it's compiling and the r200 driver seems to be working (though I only ran a few Mesa demos so far). If you want to try the branch you'll need to check out a Mesa CVS trunk tree and the DRI mesa-4-1-branch branch. Edit xc/config/cf/host.def to set the MesaSrcDir to point into the Mesa tree. Disclaimer: you're on your own if you try it and have trouble. I've got a lot of testing to do yet to iron out any obvious problems. I've tested the radeon, r200 and tdfx drivers and they seem OK. I can't test the i810, i830, r128, mga, etc drivers (either because I don't have the right hardware or mine's broke). Some of the other drivers (like sis, ffb, etc) aren't enabled in the build process and haven't been ported. I'm not sure what the status of those drivers is. I'd appreciate it if people could start testing this branch, esp the drivers I haven't tested. One thing in particular to check is the Mesa/demos/readpix program - make sure front/back buffer rendering is working. That's something that I've had to change in all the drivers. Actually, I'm not done with this yet. I've found more changes (simplifications) to make to the glDraw/ReadBuffer code. I should check it all in within a few hours. -Brian --- 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] radeon: two-sided lighting issues
I was looking into the lighting issues Felix reported with the xscreensaver pulsar hack (when running it with the -light option). One side of the planes looks good, the other one is black, so I thought it might be related to two-sided primitives. Indeed, the hardware TCL code has a fallback for this if the material is different on both sides. If I hardcode that to always trigger (in check_twoside_fallback() in radeon_state.c), pulsar looks good with lighting. So I thought I'd see if this was related to some lighting oddities in bzflag, and I made another interesting discovery: with this fallback, it locks up the chip when connecting to a server, like I reported before for software TCL. In summary, there seem to be multiple problems related to two-sided lighting in the radeon driver, both with hardware and software TCL. I'll keep looking into them, but I hope this information will help someone else find them more quickly. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast --- 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] trunk/r200: IRQs seems working, now. But DRM buildfor 2.5.40+ not.
Dieter Nützel wrote: OK, the IRQ stuff seems working currectly on my dual Athlon SMP box. I can second that, q3a works fast and stable for me, too, now! The 50-FPS-limit I used to experience is gone, and overall performance is a lot better, too demo four now gives me about 48 FPS (1280x1024@24bit, max. details, geometry high) gears is also running well (2200 FPS, with low cpu load) With and without setenv R200_NO_USLEEPS 1 I get the same numbers for Q3A. Q3A 1.32, 640x480x24 window on a 1280x1024x24 desktop, demo four: with sound: 130.3 fps wthout sound: 138.6 fps r_smp 1 quake3.x86 block, keyboard and mouse wouldn't release X server shutdown clear it --- 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] driver feature table
Leif Delgass wrote: A couple of additions I forgot: 2D XFree86 Driver: ati_drv.o + atimisc_drv.o - Fog is disabled if alpha blending is enabled. On Fri, 11 Oct 2002, Leif Delgass wrote: I think I can fill in a few blanks for mach64: Card names: 3D Rage Pro All-in-Wonder Pro Xpert 98/LCD/XL/@Play/@Work 3D Rage LT Pro 3D Rage XL 3D Rage Mobility - No hardware stencil - No mipmapping - BLEND texture env is a software fallback - texture environments which modulate alpha (AtAf) are fallbacks or non-compliant (e.g. RGBA textures with MODULATE environment are non-compliant) Correction: The ARB/EXT_texture_env_[add,dot3,combine] extensions actually are _not_ exported by default. Setting DRI_MACH64_OGL13=1 however will export these extensions and a few others to get glxinfo to report OpenGL 1.3, with the extensions being software fallbacks or no-ops. Extensions which might be doable in hardware, but not currently implemented: - EXT_paletted_texture - not sure about this, but the hardware seems to support a 2K texture palette in RGB 565. - ARB_texture_compression - would need an extension to implement 4:1 VQ texture compression supported by the hardware. Thanks for the updates, Leif. I'll post an update later. I'm thinking that if we rolled the info from the DRI Users Guide into this document we could retire the former (since it's got the old VA copyright). -Brian --- 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] radeon: two-sided lighting issues
On 11 Oct 2002 18:15:08 +0200 Michel Dänzer [EMAIL PROTECTED] wrote: I was looking into the lighting issues Felix reported with the xscreensaver pulsar hack (when running it with the -light option). One side of the planes looks good, the other one is black, so I thought it might be related to two-sided primitives. Indeed, the hardware TCL code has a fallback for this if the material is different on both sides. If I hardcode that to always trigger (in check_twoside_fallback() in radeon_state.c), pulsar looks good with lighting. So I thought I'd see if this was related to some lighting oddities in bzflag, and I made another interesting discovery: with this fallback, it locks up the chip when connecting to a server, like I reported before for software TCL. In summary, there seem to be multiple problems related to two-sided lighting in the radeon driver, both with hardware and software TCL. I'll keep looking into them, but I hope this information will help someone else find them more quickly. One observation which confused me was that it looked good if I set the alpha channel of global ambient to something other than 1.0 (or was it 0.0?) I havn't made any progress on this one. I wanted to learn more about OpenGL first and was reading Mesa code, too. And I got distracted by other problems :-| I was hoping that the transition to Mesa 4.1 may fix some of the lighting problems (tell me, if my hope is in vain.) So I won't spend too much effort now. I'll see if I can track down that gcc-3.2 wire-box issue during the weekend. Anyway, I'm amazed how quickly the work on the new branches (mesa-4-1, texmem) is proceeding. Great work! (didn't test myself yet, though ;) Cheers, Felix __\|/_____ ___ ___ __Tschüß___\_6 6_/___/__ \___/__ \___/___\___You can do anything,___ _Felix___\Ä/\ \_\ \_\ \__U___just not everything [EMAIL PROTECTED]o__/ \___/ \___/at the same time! --- 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] radeon: two-sided lighting issues
On Fre, 2002-10-11 at 18:52, Felix Kühling wrote: On 11 Oct 2002 18:15:08 +0200 Michel Dänzer [EMAIL PROTECTED] wrote: I was looking into the lighting issues Felix reported with the xscreensaver pulsar hack (when running it with the -light option). One side of the planes looks good, the other one is black, so I thought it might be related to two-sided primitives. Indeed, the hardware TCL code has a fallback for this if the material is different on both sides. If I hardcode that to always trigger (in check_twoside_fallback() in radeon_state.c), pulsar looks good with lighting. [...] I was hoping that the transition to Mesa 4.1 may fix some of the lighting problems (tell me, if my hope is in vain.) Doesn't seem to make a difference there unfortunately. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast --- 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] radeon: two-sided lighting issues
Felix Kühling wrote: On 11 Oct 2002 18:15:08 +0200 Michel Dänzer [EMAIL PROTECTED] wrote: I was looking into the lighting issues Felix reported with the xscreensaver pulsar hack (when running it with the -light option). One side of the planes looks good, the other one is black, so I thought it might be related to two-sided primitives. Indeed, the hardware TCL code has a fallback for this if the material is different on both sides. If I hardcode that to always trigger (in check_twoside_fallback() in radeon_state.c), pulsar looks good with lighting. I think this is effectively the same as setting 'R200_NO_TCL=t'. So I thought I'd see if this was related to some lighting oddities in bzflag, and I made another interesting discovery: with this fallback, it locks up the chip when connecting to a server, like I reported before for software TCL. In summary, there seem to be multiple problems related to two-sided lighting in the radeon driver, both with hardware and software TCL. I'll keep looking into them, but I hope this information will help someone else find them more quickly. One observation which confused me was that it looked good if I set the alpha channel of global ambient to something other than 1.0 (or was it 0.0?) Which makes me wonder if it's a codegen/vtxfmt problem -- what happens with R200_NO_VTXFMT=t ? 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] radeon: two-sided lighting issues
On Fri, 11 Oct 2002 18:00:18 +0100 Keith Whitwell [EMAIL PROTECTED] wrote: Felix Kühling wrote: On 11 Oct 2002 18:15:08 +0200 Michel Dänzer [EMAIL PROTECTED] wrote: I was looking into the lighting issues Felix reported with the xscreensaver pulsar hack (when running it with the -light option). One side of the planes looks good, the other one is black, so I thought it might be related to two-sided primitives. Indeed, the hardware TCL code has a fallback for this if the material is different on both sides. If I hardcode that to always trigger (in check_twoside_fallback() in radeon_state.c), pulsar looks good with lighting. I think this is effectively the same as setting 'R200_NO_TCL=t'. So I thought I'd see if this was related to some lighting oddities in bzflag, and I made another interesting discovery: with this fallback, it locks up the chip when connecting to a server, like I reported before for software TCL. In summary, there seem to be multiple problems related to two-sided lighting in the radeon driver, both with hardware and software TCL. I'll keep looking into them, but I hope this information will help someone else find them more quickly. One observation which confused me was that it looked good if I set the alpha channel of global ambient to something other than 1.0 (or was it 0.0?) Which makes me wonder if it's a codegen/vtxfmt problem -- what happens with R200_NO_VTXFMT=t ? Neither RADEON_NO_VTXFMT nor RADEON_NO_CODEGEN make any difference. Felix __\|/_____ ___ ___ __Tschüß___\_6 6_/___/__ \___/__ \___/___\___You can do anything,___ _Felix___\Ä/\ \_\ \_\ \__U___just not everything [EMAIL PROTECTED]o__/ \___/ \___/at the same time! --- 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] Sig11
Hi. I still cant use the daily snapshots - I get Sig11's and no display. Are the snapshots still not glibc2.2 compatible? I have X 4.2.1 and the latest snapshot. do I need anything else? (radeon 7500, btw) --- 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] Sig11
On Fre, 2002-10-11 at 19:21, Ian Molton wrote: I still cant use the daily snapshots - I get Sig11's and no display. Are the snapshots still not glibc2.2 compatible? That never mattered for the server. It would be interesting to know what compiler version your XFree86 was built with, and/or if the snapshot works with libxaa.a built from CVS. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast --- 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] radeon: two-sided lighting issues
Am Freitag, 11. Oktober 2002 19:07 schrieb Felix Kühling: On Fri, 11 Oct 2002 18:00:18 +0100 Keith Whitwell [EMAIL PROTECTED] wrote: Felix Kühling wrote: On 11 Oct 2002 18:15:08 +0200 Michel Dänzer [EMAIL PROTECTED] wrote: I was looking into the lighting issues Felix reported with the xscreensaver pulsar hack (when running it with the -light option). One side of the planes looks good, the other one is black, so I thought it might be related to two-sided primitives. Indeed, the hardware TCL code has a fallback for this if the material is different on both sides. If I hardcode that to always trigger (in check_twoside_fallback() in radeon_state.c), pulsar looks good with lighting. I think this is effectively the same as setting 'R200_NO_TCL=t'. So I thought I'd see if this was related to some lighting oddities in bzflag, and I made another interesting discovery: with this fallback, it locks up the chip when connecting to a server, like I reported before for software TCL. In summary, there seem to be multiple problems related to two-sided lighting in the radeon driver, both with hardware and software TCL. I'll keep looking into them, but I hope this information will help someone else find them more quickly. One observation which confused me was that it looked good if I set the alpha channel of global ambient to something other than 1.0 (or was it 0.0?) Which makes me wonder if it's a codegen/vtxfmt problem -- what happens with R200_NO_VTXFMT=t ? Neither RADEON_NO_VTXFMT nor RADEON_NO_CODEGEN make any difference. Even setenv LIBGL_ALWAYS_INDIRECT do _NOT_ help with all of my VTK apps in wire frame mode. So I point at Mesa. And my older Voodoo5 5500 (tdfx) had the same symptoms. Textures only on one side (the outer). But setenv LIBGL_ALWAYS_INDIRECT or setenv R200_NO_TCL 1 help with texturing of the outer side for the r200 case. It is broken since the TCL merge. graphics/examplesCxx setenv R200_NO_TCL 1 graphics/examplesCxx ./ColorSph [1] 9584 graphics/examplesCxx r200CreateScreen disabling TCL support [1]Fertig./ColorSph See both snapshots. -Dieter ColorSph-with-TCL.png Description: PNG image ColorSph-without-TCL.png Description: PNG image
Re: [Dri-devel] snapshot radeon-20021009 problem report: radeon_unlock
Sorry for the delay, but it has been a busy day today. The libxaa.a module build from today's CVS using gcc-2.95.3/glibc-2.2.5 is available at http://mefriss1.swan.ac.uk/~jfonseca/dri/packages/libxaa.a.bz2 This expands to some fat 6MB due to the debug info, but first try it as is before attempt to strip anything out of it. I hope this helps to discover the Sig11 problem. José Fonseca On Fri, Oct 11, 2002 at 01:22:13AM +0200, Michel Dänzer wrote: On Fre, 2002-10-11 at 00:24, José Fonseca wrote: [...] Michel, what does exactly this mean? We don't have a way to find out the version of an XFree86 module directly yet (I understand the XFree86 CVS trunk has that now). So the radeon driver tries to load version 1.1 of libxaa. If that succeeds, it knows it can use the new facilities for line acceleration. If it fails, the driver knows it's version 1.0.0 and switches to backwards compatibility mode. Would this problem (the signal 11) go away if libxaa.a was included in the binary snapshots? Maybe, maybe 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] Multimedia Design at 5$ per hour
Title: Dear Friend Dear Friend, We would like to introduce ourselves Creativeskulls, We are a new media concern having a setup of 11 high end workstations. We are looking for business partners/clients who are interested in offloading their work. Our rate is only 5 US$ for an hour of working. We have 2 master level flash certificate holders and 3 multimedia Ex. Faculty on our rolls. Our clients include Daewoo, LG India, NIIT, Modi Group (India) and now we are planning a foray in the foreign market. Please read economicaldesign.creativeskulls.com/faq.htm on the process that we follow to ensure quality, timely deliveries and economical pricing. Please visit www.creativeskulls.com/skullworks.html to see our portfolio. For further information regarding this offer please write us at [EMAIL PROTECTED] Here are some of our recent creations. Please click on the image to see a detailed view. One of our most interesting works. The photograph is of Aishwarya Rai (Miss World 1994) one of the most beautiful woman in the world. The picture that you see is made up of Approximately 10,000 individual images. Flash work is what we love to do. We have master level certificate holder from 'Brainbench' on our rolls. Our expertise in flash speaks for itself in our works. Scripting happens to be our strength. Having two ex multimedia faculty on our team gives us that edge in 3d. The samples of our work speak for themselves. We have special interest and expertise in character animation. Websites, 3d Work, Print Graphics, Corporate Presentations/Video, Flash Work, CD Rom Presentations all done at an incredible rate and incredible quality. The sample work speaks for itself. This is not a spam mail. It is a one time offer, sent to only those people, who were listed in Graphic Design sites. Just reply to us with the subject line "remove" and you will never be sent another offer mail.We did not purchase your Email id's nor do we sell any Email id's.
Re: [Dri-devel] Error installing CVS build
On Fre, 2002-10-11 at 04:27, David D. Hagood wrote: Michel Dänzer wrote: BTW I think this bug is fixed in XFree86 CVS. No, it is not. I've called this one out a few times, but it still persists. I cannot beleive I am the only one with a Radeon 7500 DW and a good monitor. You have tried XFree86 CVS as in http://www.xfree86.org/cvs/ ? -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast --- 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] Error installing CVS build
Michel Dänzer wrote: You have tried XFree86 CVS as in http://www.xfree86.org/cvs/ ? That I have NOT tried - I assumed that at that level DRI and XFree would be the same (in other words, that the primary difference would be the 3D subsystem). But I could try it, then diff the two if the problem is solved. --- 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] driver feature table
Sergey V. Udaltsov wrote: New columns for gamma, ffb, mach64, virge, sis and trident. Great work! Looks really impressive (and makes me feel really proud that my chip is not the worst one:). A couple of easy questions: is it true that Mach64 feature list is final (sure I do not mean fallback). I basically just grep'd the sources for _mesa_enable_extension() calls to find the extensions. There could certainly be mistakes in the table. Also, 3 features are marked as SW - is it good to expose them? It's actually not my question (someone already asked here before). Probably we could make exposition of non-HW-supported features optional (through XF86Config param)? Really, why inform application about things which are going to be slow? Or SW implementation of ARB/EXT_texture_env_* is fast? I don't think that we can make a blanket statement to cover this. In some cases, exposing extensions, even if they're done in software, is OK. In other cases it's silly. For example, if the hardware lacks stencil, GL_EXT_stencil_wrap might as well be supported by the driver since it's always going to be a software path. On the other hand, there's not much point exposing GL_ARB_texture_cube_map if it's in software since most apps that need it would need it to be fast to be useful. On the other (third) hand, whether or not a feature is implemented in software is not the real issue. The real issue is speed. If an app needs a particular feature to perform at a minimum level it should measure the speed itself and decide if it's fast enough. It's usually the case that hardware features are fast enough, but not always. Finally, even if a driver implements many extensions in hardware, it's always possible that software fallbacks might be needed. For example, glEnable(GL_POLYGON_SMOOTH) or glDrawBuffer(GL_FRONT_AND_BACK) often require software fallbacks. -Brian --- 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
[spyro@f2s.com: Re: [Dri-devel] snapshot radeon-20021009 problem report: radeon_unlock]
- Forwarded message from Ian Molton [EMAIL PROTECTED] - Date: Fri, 11 Oct 2002 22:11:50 +0100 From: Ian Molton [EMAIL PROTECTED] Subject: Re: [Dri-devel] snapshot radeon-20021009 problem report: radeon_unlock To: José Fonseca [EMAIL PROTECTED] On Fri, 11 Oct 2002 20:31:53 +0100 José Fonseca [EMAIL PROTECTED] wrote: The libxaa.a module build from today's CVS using gcc-2.95.3/glibc-2.2.5 is available at http://mefriss1.swan.ac.uk/~jfonseca/dri/packages/libxaa.a.bz2 This expands to some fat 6MB due to the debug info, but first try it as is before attempt to strip anything out of it. I hope this helps to discover the Sig11 problem. Works great here. I must say the new radeon driver is nice - such low CPU usage this box hasnt seen in a while on Q3 and xmms ;) props, all. - End forwarded message - --- 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] radeon: two-sided lighting issues
On Fri, Oct 11, 2002 at 06:00:18PM +0100, Keith Whitwell wrote: Felix Kühling wrote: On 11 Oct 2002 18:15:08 +0200 Michel Dänzer [EMAIL PROTECTED] wrote: I was looking into the lighting issues Felix reported with the xscreensaver pulsar hack (when running it with the -light option). One side of the planes looks good, the other one is black, so I thought it might be related to two-sided primitives. Indeed, the hardware TCL code has a fallback for this if the material is different on both sides. If I hardcode that to always trigger (in check_twoside_fallback() in radeon_state.c), pulsar looks good with lighting. I think this is effectively the same as setting 'R200_NO_TCL=t'. So I thought I'd see if this was related to some lighting oddities in bzflag, and I made another interesting discovery: with this fallback, it locks up the chip when connecting to a server, like I reported before for software TCL. In summary, there seem to be multiple problems related to two-sided lighting in the radeon driver, both with hardware and software TCL. I'll keep looking into them, but I hope this information will help someone else find them more quickly. One observation which confused me was that it looked good if I set the alpha channel of global ambient to something other than 1.0 (or was it 0.0?) Which makes me wonder if it's a codegen/vtxfmt problem -- what happens with R200_NO_VTXFMT=t ? Any chance this might be similar to the FlightGear lighting problems me and a few other people have been seeing for ages? RADEON_NO_TCL 'fixed' that, but RADON_NO_VTXFMT made no difference . . . Simon (hoping for a solution to this, finally . . .) -- PGP public key Id 0x144A991C, or http://himi.org/stuff/himi.asc (crappy) Homepage: http://himi.org doe #237 (see http://www.lemuria.org/DeCSS) My DeCSS mirror: ftp://himi.org/pub/mirrors/css/ msg06962/pgp0.pgp Description: PGP signature
Re: [Dri-devel] snapshot radeon-20021009 problem report: radeon_unlock
On 2002.10.11 21:31 José Fonseca wrote: Sorry for the delay, but it has been a busy day today. The libxaa.a module build from today's CVS using gcc-2.95.3/glibc-2.2.5 is available at http://mefriss1.swan.ac.uk/~jfonseca/dri/packages/libxaa.a.bz2 This expands to some fat 6MB due to the debug info, but first try it as is before attempt to strip anything out of it. I hope this helps to discover the Sig11 problem. This fixes the problem for me (on RH8.0, radeon snapshot). And I nearly lost the hope. I think it would be nice to have the snapshots working smoothly again, they are really useful for people like me, who would like to follow the development but the due to notorius lack of spare time cannot afford tracking CVS changes. Thanks! -pawel --- 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] radeon: two-sided lighting issues
On Fre, 2002-10-11 at 18:52, Felix Kühling wrote: On 11 Oct 2002 18:15:08 +0200 Michel Dänzer [EMAIL PROTECTED] wrote: I was looking into the lighting issues Felix reported with the xscreensaver pulsar hack (when running it with the -light option). [...] One observation which confused me was that it looked good if I set the alpha channel of global ambient to something other than 1.0 (or was it 0.0?) I may have stumbled upon this one, see the attached patch. Unfortunately, this doesn't fix the black roofs in bzflag, I wonder if it helps with flightgear... -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast Index: radeon_state.c === RCS file: /cvsroot/dri/xc/xc/lib/GL/mesa/src/drv/radeon/radeon_state.c,v retrieving revision 1.18 diff -p -u -r1.18 radeon_state.c --- radeon_state.c 25 Aug 2002 22:24:39 - 1.18 +++ radeon_state.c 12 Oct 2002 01:24:14 - @@ -885,7 +885,7 @@ void radeonUpdateMaterial( GLcontext *ct GLuint mask = ~0; if (ctx-Light.ColorMaterialEnabled) - mask = ~ctx-Light.ColorMaterialBitmask; + mask = ctx-Light.ColorMaterialBitmask; if (RADEON_DEBUG DEBUG_STATE) fprintf(stderr, %s\n, __FUNCTION__);
