Re: [Dri-devel] S3TC
Am Donnerstag, 19. Dezember 2002 19:02 schrieb Alan Cox: On Thu, 2002-12-19 at 04:40, Dieter Nützel wrote: But without kidding, couldn't you as THE well known OSS proponent get in contact with VIA the owner of S3? Several people (even Brian Paul) tried to get some wisdom out of them but they didn't get any response, yet ;-( I have a meeting with the vice president of VIA scheduled on Jan 2nd or 3rd. Thats not public info and S3TC isnt the primary item but I will mention it. Sorry, second try. I had forgotten to CC DRI-Devel. Alan, what came out of this? Regards, Dieter -- Dieter Nützel Graduate Student, Computer Science University of Hamburg Department of Computer Science home: Dieter.Nuetzel at hamburg.de (replace at with ) --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: r200: trunk Celestia texture bugs / sorry little bigger
On Son, 2003-02-23 at 12:18, Dieter Nützel wrote: After latest CVS pull texture corruption with with Celestia-1.2.5 stays. Celestia-1.2.5-Earth-r200-trunk.png before Celestia-1.2.5-Earth-r200-trunk-2.png after latest update. Several textures in fligth are broken, too. I see this with the trunk as well, but neither with the texmem nor the mesa-4-0-4 branch. -- 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: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Status of Radeon Mobility U1/320M
On Son, 2003-02-23 at 07:06, Christopher Meredith wrote: My questions: Has ATI been forthcoming with documentation for this chip? Either way, is there any active work being done on a driver for this chip? If not by DRI, does anyone here know of any work anywhere that is being done on Linuyx support for this chip? Hui Yu recently posted to an XFree86 list saying he's working on it and people can get a test driver from him. -- 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: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] It doesn't get any hotter. 8178WcCC5-019fSuA873-19
Welcome too finehornywives Whats up it's Katie. I am a 24 year old house wife. My husband is always gone on business trips, leaving me all by myself. Sometimes I get to lonely and extremly horney! My problem is solved now that I have found Fine Horney Wives. I go there and chat with women in my same situation, sometimes we meet to have a little fun, and sometimes I find a man to satisfy my wild and crazy desires. We would like to invite you to join us and maybe you could satisfy me next! Welcome too finehornywives You would not believe what is going on and what people are saying about this site, check this out! www.finehornywives.com p p p p p p p p p p p p p p p Welcome too finehornywivesfor no more offers write [EMAIL PROTECTED] 6121zLsq7-003GzSu4204vwew9-712wRbK4219dixM2-064dXYH49l50
[Dri-devel] Marbleblast UT2003.
Hello all, I thought I should send out an e-mail reporting on some changes with bugs that I initially reported on this list. With the DRI trunk and a Radeon 8500, I'm happy to say that Marbleblast now plays pretty much flawlessly. In fact, where I was getting strange rendering issues with the FireGL drivers from ATI, the DRI drivers rendering everything perfectly. The only thing I've noticed that's still lacking is an option in the game to enable stencil shadows, which doesn't seem to do anything. Is this supported with the DRI? Also, there are still pretty significant rendering errors with the latest patch for UT2003 (Patch 2199). You can see a screen shot at http://memory.visualtech.com/shot.png On the plus side, I'm no longer getting the computer lockups I was originally getting after playing the game for a few minutes. Adam --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] S3TC
On Sun, 2003-02-23 at 11:24, Dieter Ntzel wrote: I have a meeting with the vice president of VIA scheduled on Jan 2nd or 3rd. Thats not public info and S3TC isnt the primary item but I will mention it. Sorry, second try. I had forgotten to CC DRI-Devel. Alan, what came out of this? Slow progress. Stuff is happening in some areas but S3TC isn't one that yet has answers. To start with VIA apparently are only one partner in S3 --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] hey
sent_from [EMAIL PROTECTED] : A medical breakthrough in science has enabled a team of doctors and sex experts to create a pill that is designed to enlarge the male penis by length and width!Our tests show that out of 1,500 test subjects, the average gain after 4 months on VP-RX was 2.94 Inches! Amazing, Permanent results that will last!100% MONEY BACK GUARANTEE!!a href=http://members.aol.com/grtdanes33/;Click here/a to order your bottle TODAY!Or copy the link below into your browser:http://members.aol.com/grtdanes33/You are receiving this email as part of an Internet mailing list.If you wish to opt-out, and not receive any more emails from us, please a href=http://www.fasthost.bz/pink/rem;Click Here/a --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] r200 HW TCL oddities
Yes, I have an M9 now. :) I'm seeing strange behaviour in bzflag with HW TCL: sometimes, the colour and/or the lighting of some vertices seems to flicker. It seems to happen when many bullets are in flight, so it might be related to the number of light sources (lightlab shows a similar problem when enabling three light sources). Are people seeing the same thing on x86, or is this a PPC specific problem? Also, lighting with HW TCL seems to be odd in general with both r100 and r200 drivers. The best I can describe it is that vertices far away from the light source seem to be lit much too bright, e.g. in bzflag, distant walls will mostly have the color of bullets. I'm pretty sure that this problem isn't architecture specific. Could it be a bzflag problem in fact (the problem doesn't seem obvious elsewhere, but I may just not have noticed it), somehow not providing enough information for HW and SW TCL to produce the same results? Any comments or hints how I can provide better information appreciated. -- 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: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] module release method, threads, pids
Linus Torvalds wrote:
On Sat, 22 Feb 2003, Keith Whitwell wrote:
What about processes that *don't* do a close - that just use an fd and exit.
The exit does a close, and you'll see a flush() from the dying process
(and a release() if that was the last user).
In the threaded demo I'm looking at, there is only one close -- in the same
thread that did the open. The other threads just die.
If a thread does a close(), then that will have closed it in the other
threads too. You will not get any notification from the other threads,
since they will never have anything to notify about - the file is already
dead as far as they are concerned.
But sadly for me, the thread that does the open isn't the one that sees the
flush() or release() events:
Whoever does the close() generates the flush().
And the release() can be generated by anybody, although in practice it's
going to be the same one that did the final flush() in 99.99% of all cases
(but if you depend on it, you're just asking for trouble).
The last line indicates that 1063 held the lock. I never see a flush() for
that pid.
The answer really is that you shouldn't care about the pid at all.
OK, here's a patch, first attempt at doing this. It's not ready to commit
yet, unless we start a branch for this...
Things actually work pretty well, and a couple of lockups seem to have
disappeared as a result. There are at least two issues:
1) Hard lockup when the X server recycles.
2) This breaks other OS's -- they'll need to play catchup, I think.
otherwise, I'm interested in feedback.
Keith
? diff
? realdiff
? work-queue.diff
? linux/drm/kernel/diff
? shared/drm/kernel/diff
Index: linux/drm/kernel/drmP.h
===
RCS file:
/cvsroot/dri/xc/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/drmP.h,v
retrieving revision 1.56
diff -u -r1.56 drmP.h
--- linux/drm/kernel/drmP.h 11 Jan 2003 20:58:20 - 1.56
+++ linux/drm/kernel/drmP.h 23 Feb 2003 19:54:47 -
@@ -269,6 +269,17 @@
(_map) = (_dev)-context_sareas[_ctx]; \
} while(0)
+#define LOCK_TEST_WITH_RETURN( dev, filp ) \
+do { \
+ if ( !_DRM_LOCK_IS_HELD( dev-lock.hw_lock-lock ) || \
+dev-lock.filp != filp ) { \
+ DRM_ERROR( %s called without lock held\n, \
+ __FUNCTION__ ); \
+ return -EINVAL; \
+ } \
+} while (0)
+
+
typedef int drm_ioctl_t( struct inode *inode, struct file *filp,
unsigned int cmd, unsigned long arg );
@@ -317,7 +328,7 @@
__volatile__ int waiting; /* On kernel DMA queue*/
__volatile__ int pending; /* On hardware DMA queue */
wait_queue_head_t dma_wait;/* Processes waiting */
- pid_t pid; /* PID of holding process */
+ struct file *filp; /* Pointer to holding file descr */
int context; /* Kernel queue for this buffer */
int while_locked;/* Dispatch this buffer while locked */
enum {
@@ -435,7 +446,7 @@
typedef struct drm_lock_data {
drm_hw_lock_t *hw_lock; /* Hardware lock */
- pid_t pid; /* PID of lock holder (0=kernel) */
+ struct file *filp;/* File descr of lock holder (0=kernel) */
wait_queue_head_t lock_queue; /* Queue of blocked processes */
unsigned long lock_time;/* Time of last lock in jiffies*/
} drm_lock_data_t;
@@ -809,7 +820,7 @@
extern int DRM(dma_setup)(drm_device_t *dev);
extern void DRM(dma_takedown)(drm_device_t *dev);
extern void DRM(free_buffer)(drm_device_t *dev, drm_buf_t *buf);
-extern void DRM(reclaim_buffers)(drm_device_t *dev, pid_t pid);
+extern void DRM(reclaim_buffers)( struct file *filp );
#if __HAVE_OLD_DMA
/* GH: This is a dirty hack for now...
*/
Index: linux/drm/kernel/drm_bufs.h
===
RCS file:
/cvsroot/dri/xc/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/drm_bufs.h,v
retrieving revision 1.15
diff -u -r1.15 drm_bufs.h
--- linux/drm/kernel/drm_bufs.h 21 Sep 2002 23:18:54 - 1.15
+++ linux/drm/kernel/drm_bufs.h 23 Feb 2003 19:54:47 -
@@ -404,7 +404,7 @@
buf-waiting = 0;
buf-pending = 0;
init_waitqueue_head( buf-dma_wait );
- buf-pid = 0;
+ buf-filp= 0;
buf-dev_priv_size = sizeof(DRIVER_BUF_PRIV_T);
[Dri-devel] Dual-head
What is keeping DRI from working on one head of a dual-head setup (take my Radeon M7, for example). Does it require a major architectural change, or might it be something more managable that I could work on? -Jonathan Thambidurai --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Lose $ on Markets?
Title: Free Please Read: Very Important Information for You Your Future. Investment Bankers and Analysts Provide You With Information Only They Want to Hear...Their Buy Recommendations Always Seem Wrong...They Lose You Money...And All of That is While They Collect Big Fees Now You're In Charge with our FREE Letter! You can now have the same information used by professional Swiss Investors to make money in the market by trading long, short, and even using options. See for yourself. Don't miss this one-time opportunity. Subscribe for a Free Trial of our Investment Research Letter based in Basel, Switzerland Just Fill Out Our Simple Form and Receive Your One Month Free Trial Subscription Under No Obligation. Let Us Prove We Are Right Show you how to make Money! Click Here Now - don't miss out Opt-Out Instructions: We are strongly against sending unsolicited emails to those who do not wish to receive our special mailings. We have attained the services of an independent 3rd party to overlook list management and removal services. If you do not wish to receive further mailings, please visit the link below be removed from the list. Please accept our apologies if you have been sent this email in error. We honour all removes requests: Click Here --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] feel better 4795IhTr9-328tCdG0166ChSw4-600rE-30
FREE 30 day supply of HGH 1000: Look Younger and Lose Weight in 3 Weeks Visit Our Site As seen on NBC, CBS, CNN, and Oprah! The health discovery that actually reverses aging while burning fat, without dieting or exercise! This proven discovery has been reported on by the New England Journal of Medicine. Forget aging and dieting forever! And it's Guaranteed! Change your life forever! 100% GUARANTEED Visit Our Site
Re: [Dri-devel] remaining (reproducible) problems with 4.2.99.902 on Radeon M7
On Sat, Feb 22, 2003 at 12:00:03PM -0700, Keith Whitwell wrote: 3. A good old segfault: Program received signal SIGSEGV, Segmentation fault. This occurs because you have modified the X event loop to destroy a context that *IS STILL IN USE* in another thread. GL doesn't provide any guarantees about what will happen if you try to do this... Whoops, I see that now. One way to achieve something like what you want would be to make ExitFlag an array, and destroy the context at the end of draw_loop. I've attached something that does this. This doesn't solve all of your problems, though - I'm still looking at them. I was more concerned with the other two (drmCmdBuffer: -22 and the vtx assert error) in anycase, as I see them daily whilst using a VTK based application. Thanks very much for looking into this! Thanks, Charl -- charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/ --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] S3TC (again)
Can we add this to the FAQ, please? The FAQ is editable by anyone isn't it? No, but anyone can add a FAQ, if they could edit / delete them that would be none too wise, which is why I advise not to mess it up (because then I have to fix it). Liam it depends --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Website (Was: S3TC (again))
Regarding the website, I made a couple of changes to the driver feature table in /doc/feature_table.html -- primarily to add ATI_texture_env_combine3 to the list of extensions. I noticed that the link was moved from the documentation page to the status page. However, the link on the status page is to an older version of the table (/other/dri_driver_features.html), which is not as complete and doesn't have the driver notes/environment variable lists. Could you either change the link back to the newer table in /doc, or move the new table from /doc to /other, please? (neither the status page nor the table in /other are group writable). In either case, we should probably remove the old version to eliminate confusion. FYI, I also updated the cvs branch page with the new mach64 branch tag and removed some info that wasn't valid anymore from the description. --Leif On Sun, 23 Feb 2003, Smitty wrote: Can we add this to the FAQ, please? The FAQ is editable by anyone isn't it? No, but anyone can add a FAQ, if they could edit / delete them that would be none too wise, which is why I advise not to mess it up (because then I have to fix it). Liam it depends --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ 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: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Dual-head
On Mon, 2003-02-24 at 03:16, Jonathan Thambidurai wrote: On my Mobility Radeon 7500, I would like to have accelerated 3D working on one screen (primary I assume) of a Xinerama dual-head setup. As it stands, direct rendering is completely disabled upon XFree86 startup whenever two heads are used. If want to run any 3D game or application with accelerated graphics, I have to exit the X server and currently-running desktop environment completely and restart X with only a single head enabled. No, you don't. :) You can start an additional server and switch between the two, gdm makes that particularly easy. -- 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: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon 9000Pro hangs with current DRM
On Sam, 2003-02-22 at 23:04, Leif Delgass wrote: On 22 Feb 2003, Michel Dänzer wrote: On Sam, 2003-02-22 at 22:16, Leif Delgass wrote: On 22 Feb 2003, Michel Dänzer wrote: I do wonder if the register writes in RADEONSetCursorPosition() could interfere with the CP to cause FIFO overflows. Does anyone have an idea how to determine whether writes to certain registers go through the FIFO? I asked ATI devrel about this but didn't get a reply. :( The only indication that these might not is that I'd expect it to cause problems much more frequently if they did. IIRC, at least on mach64, hardware cursor position updates don't go through the draw engine FIFO Good, that makes a lot of sense of course. (any registers below dword offset 0x040 don't use the FIFO), Where did you find this information? Have you found anything similar about Radeons anywhere? It's in the register reference and programmer's guide. I don't have docs on Radeons, so I don't know if there is a similar convention there. I can't find any in the docs I have unfortunately. The SDK PDF says 'The file REGDEF.H specifically outlines the registers are FIFOed, and identifies the registers that can be read directly', but I don't see any such information in that file either. :( Maybe I'm blind... No, you're not:) Some of reference files in the Programming Guide do not match the actual files correctly. Anyway, basically most registers belonging to 2D and 3D engines are FIFOed, while the registers belonging to the display engine (like crtc, dac, cursor, fp, palette, overlay...) are not. Hui -- 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: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
