[Dri-devel] we approve Almost anyone
Let lenders compete for
your
business!
*5.25%
30 Yr Fixed Rate Mortgage!
Interest rates are at their lowest point in 40 years! We help you
find the best rate for your situation by matching your needs with
hundreds of lenders! Home Improvement, Refinance, Second Mortgage,
Home Equity Loans, and More! Even with less than perfect credit
Click Here for a Free Quote!
Lock In YOUR LOW FIXED RATE TODAY
* NO COST OUT OF POCKET
* NO OBLIGATION
* FREE CONSULTATION
* ALL CREDIT GRADES ACCEPTED
Rates as low as 5.25% won't stay this low forever CLICK HERE!
Anti-SPAM
Policy Disclaimer: Under Bill s.1618 Title III passed by the 105th U.
S. Congress, mail cannot be considered spam as long as we include contact
information and a remove link for removal from this mailing list. If this
e-mail is unsolicited, please accept our apologies. Per the proposed H.R.
3113 Unsolicited Commercial Electronic Mail Act of 2000, further
transmission
to you by the sender may be stopped at NO COST to you!
Remove
COsj6-l9áË ë^¨¥Ë)¢{(ç[É8bAzEÊ&zÚ yé!y«Þm§ÿí)äç¤r¿±ðëׯzYX§X¬´:âuëÞX¬¶Ë(º· ~àzwÛi³ÿåËl²«qç讧zßåËlþX¬¶)ߣ÷kׯz
[Dri-devel] dri-devel, Licensed Pharmacists, Free Doctor Consultation! Gen*ric V*agra
Title: rjwoiwqmob
Dear dri-devel
Generic Viagra
Value
Drugstore
For the first
time ever a generic equivalent to Viagra® is available. Generic Sildenafil Citrate
(GSC-100) and Viagra® both consist of 100 mg of sildenafil citrate. GSC-100 is simply a
generic version of Viagra® - just like ibuprofen is the generic name for Advil®.
Click here to visit our site
Dr. Ves
Kiril, MD.
Director of
Urological Services
Product:
GSC-100
100mg
Sildenafil Citrate
Vs.
Viagra®
100mg
Sildenafil Citrate
Cost:
As low as $5.00 US per 100mg tablet
$12.25 US per 100mg tablet
Physician Consultation:
Included in Pricing
$75.00 - $100.00 doctors visit
Convenience:
10 minute online consultation right
now
Up to 4 hours
Doctor visit: 1-3 hours
Pharmacy pickup: ½ - 1 hour
100% Money Back Guarantee:
YES, the first drug ever to be
guaranteed
NO
Delivery:
1-2 days after payment verification - FREE SHIPPING
When can your doctor see you?
rjwoiwqmob
Visit our site
Limited Time Offer: 15 pills for $119.00
Why pay
twice as much when GSC-100 is
the same thing and is only a click away?
rjwoiwqmob
Copyright © 2002 Generic Viagra. All
rights reserved.
100%
Money Back Guarantee - The First Pharmaceutical to ever be guaranteed
Viagra® is a trademark of the Pfizer, Inc. and is not affiliated with Generic Viagra.
áË ë^¨¥Ë)¢{(ç[É8bAzEÊ&zÚ yé!y«Þm§ÿí)äç¤r¿±ðëׯzYX§X¬´:âuëÞX¬¶Ë(º· ~àzwÛi³ÿåËl²«qç讧zßåËlþX¬¶)ߣ÷kׯz
[Dri-devel] Xft (RENDER?) + 4.2.0 + DRI binary snapshots == signal 11
Dear list, Can anyone (especially those running a current DRI binary snapshot installed over an XFree86 4.2.0 installation) confirm an X crash (signal 11) reproducible by starting any Xft-using application, i.e. anything that renders anti-aliased fonts? E.g. on my laptop xterm -fa mono does the trick. Any information on this would be greatly appreciated... I know that just installing a CVS build would work, but I like to know that the binary snapshots also work. Thanks, Charl -- charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/ --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Radeon: lockup on state change
Felix Kühling wrote: On Sun, 8 Dec 2002 14:24:58 +0100 Felix Kühling <[EMAIL PROTECTED]> wrote: Hi, as I reported earlier there seems to be a race condition in the Radeon driver when state is emitted while the card is processing vertices. Now Keith, I just read your other message. Ok, so let's call it "failure" ;-) I narrowed it down to tex[0], tex[1] and tcl states that appear to require 3D to be idle. Can someone with Radeon specs confirm this? Other That's exactly what you asked for :). More precisely, if TCL was disabled I had to wait before emitting texture changes. If TCL was enabled it was enough to wait before emitting TCL state. But this may be due to the order of state changes. If TCL state is always emitted before texture state, then waiting before the TCL state will also ensure that 3D is idle before the texture state change. Felix, I've committed the first version for now, because 1) it's cleaner 2) it emits at most 1 wait per statechange 3) I'm not convinced that there are many statechanges that don't touch any of tcl, tex0 or tex1 -- ie I think the second version would emit a wait on *almost* every statechange. If you want to narrow the lockup conditions down further, feel free & I'll commit the results. Keith --- 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] problem with large textures on Radeon
Hi all, Again, Michel D\"anzer suggested to mail this problem to this list. This is what I wrote him: I'm a beta tester of the upcoming MSX emulator openMSX (see openmsx.sf.net). This emulator also has a renderer based on the SDL GL library. However, it seems that some things go wrong with this renderer in its current implementation on my Ati Radeon 32MB SDR (and you know I'm using the drivers from your site). The author of this GL renderer, Maarten ter Huurne, suggested that the problem was in my drivers. This is an original e-mail (partly snipped): Original Message Subject: Re: [openMSX-devel] Web site Date: Sun, 1 Dec 2002 20:05:01 +0100 From: Maarten ter Huurne <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] > It's not that broken if it works on everybody's computer except > yours... The code assumes textures of width 1024 are available, which is true for some GFX cards and not for others. However, it seems this problem also stops all other texture mapping on Manuel's PC, I don't know whether that is correct behaviour by the OpenGL spec or whether that is a driver bug (I guess the latter). The problem is that Maarten uses textures of 1024 pixels wide, which has the effect that on my system the whole window stops being rendered. I just get to see some old VRAM data of the GFX card (like parts of previously run GL programs or so). This is how I described it in another mail: > Well, only in the openMSX window, not on the whole PC... ;-) > > > behaviour by the OpenGL spec or whether that is a driver bug (I guess > > the latter). > > It is strange then that practically all other openGL apps work fine! > (OK, there are some glitches here and there, but nothing as serious > as this...) > > Before my SDLGL went completely dead, I was also still having the > problem that any Console background is completely white in the GL > renderer... > > I'm sure that I'm not the only one who has this problem. But most > people here have NVidia cards, I guess. Can you enlighten us about this problem? Is it indeed a driver bug or problem? - Michel suggested it was a problem due to low texture memory: > Yes, it's probably the bug discussed on dri-devel, triggered by low > texture memory. However, this is his reply on my reply to that: > I configured X to run in 1024x768, which gives me 17MB for textures > (instead of the 2752kB at 1600x1200), according to the X log. The > problem is still there. (As opposed to the Tux Racer problem, which is > gone then, as previously reported...) > > ...? Hmm, no idea then, seems to be a different problem after all. Please post to dri-devel again. Anyone else who knows what might be the problem? Best regards, Manuel Bilderbeek --- 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] Been234It's YOUR MONEY!!! Been234
To un-subscribe click here ALL un-subscribe requests are honored 5729XzhI1-254ogEn8807CaUI7-745QFwr9062XJTI7-384KqyT5402uUcB9-910bjvd6728Ql69+,~wzf¢+,¦ì¢·o$áyyézW(ëhç¤ æ¯zxm¶ÿ¶§Ê&þÇî'^½éfj)b b²ÐëׯzYb²Û,¢êÜyú+éÞ¶m¦Ïÿ+-²Ê.Ç¢¸ ë+-³ùb²Ø§~Ý®'^½é
[Dri-devel] Re: Radeon: lockup on state change
On Sun, 8 Dec 2002 14:24:58 +0100 Felix Kühling <[EMAIL PROTECTED]> wrote: > Hi, > > as I reported earlier there seems to be a race condition in the Radeon > driver when state is emitted while the card is processing vertices. Now Keith, I just read your other message. Ok, so let's call it "failure" ;-) > I narrowed it down to tex[0], tex[1] and tcl states that appear to > require 3D to be idle. Can someone with Radeon specs confirm this? Other That's exactly what you asked for :). More precisely, if TCL was disabled I had to wait before emitting texture changes. If TCL was enabled it was enough to wait before emitting TCL state. But this may be due to the order of state changes. If TCL state is always emitted before texture state, then waiting before the TCL state will also ensure that 3D is idle before the texture state change. > state changes may not lock up the card but cause incorrect rendering. I > havn't seen such behaviour, though. Again, what do the specs say? You say, the card should know how to handle this. So if no one has seen any problems so far, let's assume that's the case :) > A refined patch for the user space driver is attached. A proper fix in > the kernel would have to check the packet id in radeon_emit_packets > (shared/drm/kernel/radeon_state.c) once we know exactly which packets > are affected. > 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] Radeon: race condition on state change
Hi,
as I reported earlier there seems to be a race condition in the Radeon
driver when state is emitted while the card is processing vertices. Now
I narrowed it down to tex[0], tex[1] and tcl states that appear to
require 3D to be idle. Can someone with Radeon specs confirm this? Other
state changes may not lock up the card but cause incorrect rendering. I
havn't seen such behaviour, though. Again, what do the specs say?
A refined patch for the user space driver is attached. A proper fix in
the kernel would have to check the packet id in radeon_emit_packets
(shared/drm/kernel/radeon_state.c) once we know exactly which packets
are affected.
Regards,
Felix
__\|/_____ ___ ___
__Tschüß___\_6 6_/___/__ \___/__ \___/___\___You can do anything,___
_Felix___\Ä/\ \_\ \_\ \__U___just not everything
[EMAIL PROTECTED]>o<__/ \___/ \___/at the same time!
Index: radeon_ioctl.c
===
RCS file: /cvsroot/dri/xc/xc/lib/GL/mesa/src/drv/radeon/radeon_ioctl.c,v
retrieving revision 1.37
diff -u -r1.37 radeon_ioctl.c
--- radeon_ioctl.c 30 Nov 2002 14:24:06 - 1.37
+++ radeon_ioctl.c 8 Dec 2002 13:21:06 -
@@ -87,6 +87,14 @@
foreach_s( state, tmp, list ) {
if (state->check( rmesa->glCtx )) {
+if (state == &rmesa->hw.tex[0] || state == &rmesa->hw.tex[1] ||
+state == &rmesa->hw.tcl) {
+drmRadeonCmdHeader *cmd;
+cmd = (drmRadeonCmdHeader *)radeonAllocCmdBuf( rmesa, sizeof(*cmd),
+ __FUNCTION__ );
+cmd->wait.cmd_type = RADEON_CMD_WAIT;
+cmd->wait.flags = RADEON_WAIT_3D;
+}
dest = radeonAllocCmdBuf( rmesa, state->cmd_size * 4, __FUNCTION__);
memcpy( dest, state->cmd, state->cmd_size * 4);
move_to_head( &(rmesa->hw.clean), state );
Re: [Dri-devel] trunk and glaxium
Felix Kühling wrote: On 07 Dec 2002 02:07:03 +0100 Michel Dänzer <[EMAIL PROTECTED]> wrote: On Die, 2002-12-03 at 23:17, Felix Kühling wrote: I just tried glaxium myself. And it freezes the Xserver here too. However, I don't have to move the window :-/ it always freezes about 3 seconds after I enter the game. I also tried it without TCL. Then it seemed to run fine (at least a few seconds longer than usual) and locked up as soon as I pushed a button. I also get the error message about IrqWait. That probably means that the hardware stops generating interrupts and is in some messed-up state. Would it be helpful for a developer with Radeon specs to see the last DMA buffer that was submitted to the card before it locked up? Unfortunately, the specs are missing a section 'DMA command streams which cause lockups'. ;) I could dump DMA buffers to a file and insert a radeonWaitForIdle right after submitting (and dumping) DMA buffers, so I'm sure I really get the last one *before* the card locks up. This sounds like a good plan for you to debug this though. I think I tracked it down to a race condition. If state is emitted while the card is still processing vertices this could be a potential problem, especially if things like texture offsets and sizes are changed. As a workaround I emit a RADEON_WAIT_3D into the cmd buffer before emitting state in radeon_emit_state_list. A patch is attached. This is really just a workaround. A proper fix would have to be in the kernel since a malicious client could still exploit the race condition. I think it's misleading to label this as a race - you don't know enough about what's happening inside the card to call it one thing or another. What it is is a workaround for a unspecified failure that may be a hardware bug, or may be some unknown bug in the way we put together command streams, or in fact might be any one of a zillion other things. I'd be interested to see if you can narrow down the circumstances in which it's necessary to emit this as it looks fairly heavy handed -- effectively disables all state pipelining in the hardware. Graphics cards not only know how to (normally) avoid statechanges scribbling on in-process vertices, they know how to handle statechanges without the overhead of a full pipeline flush. It would be interesting to try and figure out which state changes are responsible for the lockups you're seeing... 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
