Re: [Dri-devel] reproducible VTK + DRI breakage
Charl P. Botha wrote: Dear list, I've attached a wxPython + VTK example (just the wxVTKRenderWindowInteractor.py slightly modified) to illustrate the drmCmdBuffer: -22 bug that I'm actually seeing. It seems my glthreads.c attempts were off the track. In anycase, if you have wxPython and VTK with working Python wrappings installed, please run the attached example. Manipulate the 3D cone in both windows and then close the one window. Manipulating the remaining 3D cone for a second or two should result in a drmCmdBuffer: -22 application crash. If anyone 1. can replicate this or 2. fix it ;) I would be most grateful. Thanks, Charl Charl (and Dieter), You'll be pleased to hear that I've now got access to a HT enabled box with which I can reproduce some or all of the problems you guys have been seeing with threaded apps. Hopefully there'll be some fixes soon. 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] reproducible VTK + DRI breakage
On Tue, 2003-03-11 at 10:16, Keith Whitwell wrote: Charl P. Botha wrote: In anycase, if you have wxPython and VTK with working Python wrappings installed, please run the attached example. Manipulate the 3D cone in both windows and then close the one window. Manipulating the remaining 3D cone for a second or two should result in a drmCmdBuffer: -22 application crash. You'll be pleased to hear that I've now got access to a HT enabled box with which I can reproduce some or all of the problems you guys have been seeing with threaded apps. Hopefully there'll be some fixes soon. Hmmm, new toys to play with! Thanks for thinking about us. ;) Keith, your filp-1 patch completely killed the drmCmdBuffer: -22 bug on my box. I have not been able to reproduce it since with VTK or synthetic tests. Thanks again, 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: [Mesa3d-dev] Re: [Dri-devel] Mesa C++ driver framework update
José Fonseca [EMAIL PROTECTED] writes: | On Mon, Mar 10, 2003 at 11:59:05PM +, Keith Whitwell wrote: | | Unless C++ can figure out at compile time *exactly* which class is being | invoked, I think... It's hard to know. | | It can, with templates. Even with no templates, current C++ compilers can detect that in case the function is called through actual objcets (i.e. the dynamic type equals the static type). GCC at least does that. One compiler (KIA's) even used to do more with virtual calls through pointers. -- Gaby --- 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: [Mesa3d-dev] Re: [Dri-devel] Mesa C++ driver framework update
No, because one of the things C++ does is pass around an extra parameter -- namely the 'self' pointer. The 'real' prototype looks something like: void Context::BlendFunc( Context *self, GLenum sfactor, GLenum dfactor ) Thats correct, but not with static methods (please correct me, if it isn't), callbacks are a little be tricky to implement in C++ if you don't know how, but this should be no nogo item. regards odiX --- 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: [Mesa3d-dev] Re: [Dri-devel] Mesa C++ driver framework update
Gabriel Dos Reis wrote:
Keith Whitwell [EMAIL PROTECTED] writes:
[...]
| struct function_table {
|...
|void (*BlendFunc)(GLcontext *ctx, GLenum sfactor, GLenum dfactor);
|...
| } driver;
| and
| class Context {
|...
|void BlendFunc(GLenum sfactor, GLenum dfactor);
|...
| } ;
| You can't simply do
|driver.BlendFunc = Context::BlendFunc;
| or can you?
|
| No, because one of the things C++ does is pass around an extra parameter --
| namely the 'self' pointer. The 'real' prototype looks something like:
|
| void Context::BlendFunc( Context *self, GLenum sfactor, GLenum dfactor )
|
| -- but there's no guarentee that this is actually what is happening,
| or that it won't change.
All that is right.
| Yes, I know there is an ABI now -- but I've
| no idea what it actually specifies.
And it helps to remember that that cross-vendor ABI is not supported
by Microsoft and not every vendor supports it currently. At any rate,
I would suggest against mocking around the ABI.
| Does it allow the compiler to try
| figure out if self is needed? If BlendFunc doesn't reference it,
| does it go away, or is it always passed even if its not needed?
If self is not used, then I think the compiler makes it go away.
But if it's a virtual function, it can't because it might be needed in some
other implementation...
As I once mentioned, it can be difficult to guess whats going on at a low
level by looking at C++ code. That's fine for 95% of the driver, but not so
good for the remaining 5% -- and it's really that 5% that interests me most.
Coincidentally, the example that started this discussion was set in that 5%.
All in all I'm broadly in favour of a C++ framework where it can enhance
sharing between the drivers and doesn't further obscure the functioning of the
code.
[...]
| This is something that C++ does internally, but for GL driver
| development you are probably better off doing it explicitly, as you
| have to at the libGL.so layer anyway.
I didn't understand why that needs to be done explicitly. Plesse,
could you elaborate?
I was talking about the dispatch layer that already exists inside libGL.so, I
think... I talked about this with Marcello in other posts.
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] reproducible VTK + DRI breakage
Charl P. Botha wrote: On Tue, 2003-03-11 at 10:16, Keith Whitwell wrote: Charl P. Botha wrote: In anycase, if you have wxPython and VTK with working Python wrappings installed, please run the attached example. Manipulate the 3D cone in both windows and then close the one window. Manipulating the remaining 3D cone for a second or two should result in a drmCmdBuffer: -22 application crash. You'll be pleased to hear that I've now got access to a HT enabled box with which I can reproduce some or all of the problems you guys have been seeing with threaded apps. Hopefully there'll be some fixes soon. Hmmm, new toys to play with! Thanks for thinking about us. ;) Keith, your filp-1 patch completely killed the drmCmdBuffer: -22 bug on my box. I have not been able to reproduce it since with VTK or synthetic tests. Can you summarize the problems that remain? I'm seeing all manner of bad behaviour with glthreads - lots of GL_INVALID_OPERATION errors, lots of 'holds heavyweight lock' errors, the occasional lockup. It's a mess... 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: [Mesa3d-dev] Re: [Dri-devel] Mesa C++ driver framework update
Keith Whitwell [EMAIL PROTECTED] writes:
[...]
| struct function_table {
|...
|void (*BlendFunc)(GLcontext *ctx, GLenum sfactor, GLenum dfactor);
|...
| } driver;
| and
| class Context {
|...
|void BlendFunc(GLenum sfactor, GLenum dfactor);
|...
| } ;
| You can't simply do
|driver.BlendFunc = Context::BlendFunc;
| or can you?
|
| No, because one of the things C++ does is pass around an extra parameter --
| namely the 'self' pointer. The 'real' prototype looks something like:
|
| void Context::BlendFunc( Context *self, GLenum sfactor, GLenum dfactor )
|
| -- but there's no guarentee that this is actually what is happening,
| or that it won't change.
All that is right.
| Yes, I know there is an ABI now -- but I've
| no idea what it actually specifies.
And it helps to remember that that cross-vendor ABI is not supported
by Microsoft and not every vendor supports it currently. At any rate,
I would suggest against mocking around the ABI.
| Does it allow the compiler to try
| figure out if self is needed? If BlendFunc doesn't reference it,
| does it go away, or is it always passed even if its not needed?
If self is not used, then I think the compiler makes it go away.
[...]
| This is something that C++ does internally, but for GL driver
| development you are probably better off doing it explicitly, as you
| have to at the libGL.so layer anyway.
I didn't understand why that needs to be done explicitly. Plesse,
could you elaborate?
-- Gaby
---
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] reproducible VTK + DRI breakage
Keith Whitwell wrote: Charl P. Botha wrote: On Tue, 2003-03-11 at 10:16, Keith Whitwell wrote: Charl P. Botha wrote: In anycase, if you have wxPython and VTK with working Python wrappings installed, please run the attached example. Manipulate the 3D cone in both windows and then close the one window. Manipulating the remaining 3D cone for a second or two should result in a drmCmdBuffer: -22 application crash. You'll be pleased to hear that I've now got access to a HT enabled box with which I can reproduce some or all of the problems you guys have been seeing with threaded apps. Hopefully there'll be some fixes soon. Hmmm, new toys to play with! Thanks for thinking about us. ;) Keith, your filp-1 patch completely killed the drmCmdBuffer: -22 bug on my box. I have not been able to reproduce it since with VTK or synthetic tests. Can you summarize the problems that remain? I'm seeing all manner of bad behaviour with glthreads - lots of GL_INVALID_OPERATION errors, lots of 'holds heavyweight lock' errors, the occasional lockup. It's a mess... Ah, actually this was my fault. Missed an installation step on the new box... glthreads is running ok here, now. Which is good -- but can you still post a summary of outstanding issues. I don't have vtk installed, but will do so if necessary. 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] reproducible VTK + DRI breakage
Keith, Do you want to try running two copies of the 'tunnel' demo ? Alan. --- 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] reproducible VTK + DRI breakage
On Tue, 2003-03-11 at 12:44, Keith Whitwell wrote: Ah, actually this was my fault. Missed an installation step on the new box... glthreads is running ok here, now. Which is good -- but can you still post a summary of outstanding issues. I don't have vtk installed, but will do so if necessary. If we're talking only DRI with your filp-1 changes, I actually have no outstanding threading problems! I seem to recall Dieter having a test case with multiple glxgears and an ipers that broke badly, but he will probably bring that up again. On 4.3.0 however, the vtxfmt assert error (and application termination) seems to happen very often with applications with multiple glxcontexts. The problem seems to have been solved in current DRI CVS, but I haven't been able to track down the fixer/fix (I would love backporting this to 4.3.0). Thanks again, 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] drm-filp-0-1-branch and radeon
Keith Whitwell wrote:
Linus Torvalds wrote:
On Sun, 2 Mar 2003, Linus Torvalds wrote:
The _second_ DRI-enabled X startup caused problems, even if I had done
multiple non-DRI X sessions in between. This is what makes me think that
the DRI kernel modules keep some history around that they shouldn't.
And
maybe the problem is hidden if you actually unload and re-load the
modules (is that what most people do?)
Ok, I went in and looked for suspicious behaviour, and I found some.
Look at AGP and MTRR behaviour: both of them are initialized by
drm_init() at module load time.
Both of them are _de-initialized_ by the DRM(takedown)() code, and
never
re-initialized by the DRM(setup)() code.
So an example of badness would be:
- load DRM modules (in my case as part of kernel bootup, since they
arecompiled in):
- initialize MTRR and AGP mappings
- run X with DRI.
- Everything is happy.
- exit DRI X
- we are the last close case for DRI, so DRM(release)() calls
DRM(takedown)(), which frees AGP and MTRR
- restart non-DRI X
- nothing happens
- kill non-DRI X
- nothing happens
- run X with DRI again
- oops. We now have neither AGP nor MTRR's set up, even though
the code looks like it is assuming it.
Yeah, maybe I'm missing where somebody else re-initializes AGP and
MTRR, but my point is that these things do not seem to nest
correctly. That mtrr_del() in particular seems to be wrong, and I do
indeed get a
mtrr: MTRR 2 not used
when shutting down X normally.
Comments? I haven't really gone through the whole path of what happens
at open()/release() time, and these are really nothing more than that
looks suspicious, maybe somebody who knows the code better than I can
take a better look at it.
Yes it looks suspicious, but I don't think it's the cause of the lockups
on X recycle.
Evidence for this:
- The lockup is new, while the code has been suspicious forever...
- I can exit and restart X just fine, it's only recycle that locks.
From the kernel point of view, these should be the same.
- In the Mesa embedded branch, I have a demo that closes reopens
its connections to the kernel without exiting. Again this works fine.
I've also verified that this lockup wasn't introduced in the filp work,
ie. it had already sneaked into the trunk somehow.
OK, I've had some time to track this down. It comes down to the changes
introduced to radeon_driver.c around 29 Oct last year.
revision 1.45
date: 2002/10/29 13:49:25; author: mdaenzer; state: Exp; lines: +30 -19
* preserve CRTC{,2}_OFFSET_CNTL in 2D driver to avoid bad effects when
pageflipping after a mode switch
* take current page into account in AdjustFrame(); writing the CRTC offset
via the CP was probably a bad idea as this can happen asynchronously,
reverted
* take frame offset into account when flipping pages
* handle CRTC2 as well for pageflipping (untested)
* preserve GEN_INT_CNTL on mode switches to prevent interrupts from getting
disabled
Michel, have you got time to look into why this is causing server recycles to
hang? I can't reproduce it on all machines, so it's possible that your test
box is one of the ones unaffected by this lockup -- if you can't reproduce,
let me know...
I'll poke around in the meantime try figure it out.
Keith
---
This SF.net email is sponsored by:Crypto Challenge is now open!
Get cracking and register here for some mind boggling fun and
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] drm-filp-0-1-branch and radeon
On Die, 2003-03-11 at 14:41, Keith Whitwell wrote:
Keith Whitwell wrote:
Evidence for this:
- The lockup is new, while the code has been suspicious forever...
- I can exit and restart X just fine, it's only recycle that locks.
From the kernel point of view, these should be the same.
- In the Mesa embedded branch, I have a demo that closes reopens
its connections to the kernel without exiting. Again this works fine.
I've also verified that this lockup wasn't introduced in the filp work,
ie. it had already sneaked into the trunk somehow.
OK, I've had some time to track this down. It comes down to the changes
introduced to radeon_driver.c around 29 Oct last year.
revision 1.45
date: 2002/10/29 13:49:25; author: mdaenzer; state: Exp; lines: +30 -19
* preserve CRTC{,2}_OFFSET_CNTL in 2D driver to avoid bad effects when
pageflipping after a mode switch
* take current page into account in AdjustFrame(); writing the CRTC offset
via the CP was probably a bad idea as this can happen asynchronously,
reverted
* take frame offset into account when flipping pages
* handle CRTC2 as well for pageflipping (untested)
* preserve GEN_INT_CNTL on mode switches to prevent interrupts from getting
disabled
Whoops. I plead guilty. :\
Michel, have you got time to look into why this is causing server recycles to
hang?
Unfortunately not really right now... I'll try to, anyway.
I can't reproduce it on all machines, so it's possible that your test
box is one of the ones unaffected by this lockup -- if you can't reproduce,
let me know...
I haven't been able to reproduce it yet, but then I haven't tried very
hard (gdm defaults to restarting the server these days).
--
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:Crypto Challenge is now open!
Get cracking and register here for some mind boggling fun and
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Corrupted textures on 64bit tuxracer
On x86_64 (probably any 64bit arch also, but I haven't tested ia64 or alpha yet), tuxracer experiences texture corruption on ice patches and the sides of some hills. This is occurs on the very first race, so it's not hard to reproduce. AS you're gliding along, the grey patch approaches and flickers terribly, but the portions that are white snow seem to work fine. This is using XFree86 4.3.0 on a Radeon 7500 under a 64bit kernel with 64bit X. Everything is stable (doesn't crash), just the graphic glitches described above. Just wondering if anyone else experiences this on 64bit archs with tuxracer to help determine if it might be a bug in the game, or a bug on the X side of things. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Corrupted textures on 64bit tuxracer
On Die, 2003-03-11 at 17:01, Mike A. Harris wrote: On x86_64 (probably any 64bit arch also, but I haven't tested ia64 or alpha yet), tuxracer experiences texture corruption on ice patches and the sides of some hills. This is occurs on the very first race, so it's not hard to reproduce. AS you're gliding along, the grey patch approaches and flickers terribly, but the portions that are white snow seem to work fine. This is using XFree86 4.3.0 on a Radeon 7500 under a 64bit kernel with 64bit X. Everything is stable (doesn't crash), just the graphic glitches described above. Just wondering if anyone else experiences this on 64bit archs with tuxracer to help determine if it might be a bug in the game, or a bug on the X side of things. Have you verified it's 64 bit specific at all? This sounds like the known tuxracer problem with environment mapping, which is a tuxracer bug strictly speaking (it should use polygon offsets) but can be worked around with RADEON_TCL_FORCE_DISABLE=1. -- 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:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] reproducible VTK + DRI breakage
On Die, 2003-03-11 at 13:51, Charl P. Botha wrote: On Tue, 2003-03-11 at 12:44, Keith Whitwell wrote: Ah, actually this was my fault. Missed an installation step on the new box... glthreads is running ok here, now. Which is good -- but can you still post a summary of outstanding issues. I don't have vtk installed, but will do so if necessary. If we're talking only DRI with your filp-1 changes, I actually have no outstanding threading problems! I seem to recall Dieter having a test case with multiple glxgears and an ipers that broke badly, but he will probably bring that up again. On 4.3.0 however, the vtxfmt assert error (and application termination) seems to happen very often with applications with multiple glxcontexts. The problem seems to have been solved in current DRI CVS, but I haven't been able to track down the fixer/fix (I would love backporting this to 4.3.0). This may be stating the obvious, but RADEON_NO_VTXFMT=1 should work around the problem, right? -- 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:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Double define for radeon data structures?
Hi all, This is my first post, be patient, please! :) I'm reading radeon code on CVS. In radeon_drm.h, on kernel side, I can see a lot of data structures already defined on client side in radeon_sarea.h. They are about shared area, but also about data types used by IOCTLs and register defines. They have same data members but sometimes different names. Is there a specific need for this? Can I simply define everything in one file and import it in both kernel and client components? Thanks in advance! Guido --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Double define for radeon data structures?
Guido Landra wrote: Hi all, This is my first post, be patient, please! :) I'm reading radeon code on CVS. In radeon_drm.h, on kernel side, I can see a lot of data structures already defined on client side in radeon_sarea.h. They are about shared area, but also about data types used by IOCTLs and register defines. They have same data members but sometimes different names. Is there a specific need for this? Can I simply define everything in one file and import it in both kernel and client components? It would be nice easy, wouldn't it. Unfortunately for us, XFree86 coding standards don't permit operating system files to be directly included in the drivers -- even when the portion of the operating system is being supplied by XFree86. Keith --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] reproducible VTK + DRI breakage
On Die, 2003-03-11 at 18:37, Charl P. Botha wrote: On Tue, 2003-03-11 at 18:29, Michel Dänzer wrote: On Die, 2003-03-11 at 13:51, Charl P. Botha wrote: On 4.3.0 however, the vtxfmt assert error (and application termination) seems to happen very often with applications with multiple glxcontexts. The problem seems to have been solved in current DRI CVS, but I haven't been able to track down the fixer/fix (I would love backporting this to 4.3.0). This may be stating the obvious, but RADEON_NO_VTXFMT=1 should work around the problem, right? AFAICR (I don't have my laptop with me) it does. However, I would prefer to have this done The Right Way(tm). Sure, just pointing out that this isn't a showstopper until the fix is backported. Someone also sent me your radeon flushvertices patch that I still have to try on 4.3.0. I'd be surprised if that helped this. Keith probably fixed this, look for his post mesa-4-0-4-branch trunk commits. -- 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:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Stay young with our product. ocqhqoviwj fqjhcji
*As seen on TV* The health discovery that reverses signs of aging naturally and that is completely safe and effective is on sale for a limited time! Buy a two-month supply of our product and we will give you one month free! All natural H_G_H Enhancer will help you with all of the following: - Reduce body fat and build muscle - Enrich your sex life - Help remove cellulite and wrinkles - Sleep better, improve vision and memory - Restore hair growth and color - Strengthen your immune system - Have more energy - Turn back time on your body's biological clock up to twenty years with just six months of use! *** IF YOU ARE NOT COMPLETELY SATISFIED WITH OUR PRODUCT WE WILL REFUND YOU YOUR MONEY, NO QUESTIONS ASKED *** Click here to view our site or paste http://www.healthproducts.bz/human/index.php?show=main=751 into your web browser sh m c
Re: [Dri-devel] Corrupted textures on 64bit tuxracer
On Tue, Mar 11, 2003 at 11:01:59AM -0500, Mike A. Harris wrote: On x86_64 (probably any 64bit arch also, but I haven't tested ia64 or alpha yet), tuxracer experiences texture corruption on ice patches and the sides of some hills. This is occurs on the very first race, so it's not hard to reproduce. AS you're gliding along, the grey patch approaches and flickers terribly, but the portions that are white snow seem to work fine. Wierd. I used a radeon 7500 to develop the x86-64 agpgart code, _and_ I used tuxracer almost exclusively to test it, and hadn't noticed any problems. I'll upgrade X to our latest beta rpm in a while, and see if I can reproduce here, as its been a while since I tested it (definitly before 4.3.0 came out). Just wondering if anyone else experiences this on 64bit archs with tuxracer to help determine if it might be a bug in the game, or a bug on the X side of things. It sounds like a DRI regression, although it could also be something as subtle as toolchain problems. During early agpgart development, broken gcc's made some really wacky effects happen in tuxracer 8-) Dave -- | Dave Jones.http://www.codemonkey.org.uk | SuSE Labs --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: dri_driver_features.phtml dri_radeon_features.html
Smitty wrote: Hi Brian In light of your well maintained: http://dri.sourceforge.net/doc/dri_driver_features.phtml I think it's about time that: http://dri.sourceforge.net/doc/dri_radeon_features.html crawled into a hole and died. Do you want to pull in anything from this page or can I get rid of it (permanently)? As far as I'm concerned you can remove the later. It goes into more detail than I think is necessary. The status page seems redundant too: http://dri.sourceforge.net/dri_status.phtml When one clicks on Status on the left (or page header) I think the new table page should come up. -Brian --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] drmScatterGatherAlloc missing from docs
http://dri.sourceforge.net/doc/drm_low_level.html should be updated with a functional description of drmScatterGatherAlloc() [and probably a few other drmXXXYYY() routines that have appeared since 1999 ;-) ] --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [XFree86] S3 Virge (3D)
Bellard, Karen L wrote: I have a HP Pavilion 7410P and it has S3 Virge (3D). Can this support OpenGL? It is /possible/, but the driver is not complete. There is a branch in the DRI tree where this work was being done. The person that was working on it seems to have stopped working on it a few months ago. At that time the driver supported one particular version of the Virge fairly well, but I seem to recall that it either had serious problems or flat didn't work on other versions of the chip. I'm CCing dri-devel in case someone on there remembers... --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
