Re: [Dri-devel] Adding GLX extensions?
Ian Romanick wrote: Hmmm...would adding it as a hard-coded extension make life easier for IHVs that want to provide binary-only drivers but not necessarilly their own libGL.so? I'm thinking ATI and PowerVR... Oddly enough, ATI provides a libGL.so replacement in their package. I'm not sure why they do this. The Linux user base would really benefit from driver packages that didn't interfere with each other. Replacing a critical library like libGL.so has a major impact on the other drivers loaded on the system. I'm not just picking on ATI, here...NVidia does this, too. PowerVR is a good example of a well thought out install package. -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] Adding GLX extensions?
-Original Message- From: Ian Romanick [mailto:[EMAIL PROTECTED]] Sent: 15 November 2002 20:40 To: DRI developer's list Subject: Re: [Dri-devel] Adding GLX extensions? [...] Hmmm...would adding it as a hard-coded extension make life easier for IHVs that want to provide binary-only drivers but not necessarilly their own libGL.so? I'm thinking ATI and PowerVR... yes, it would make our life easier :) [...] Vlad Stamate www.powervr.com --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: mesa-4-1-branch)
Brian Paul wrote: Keith Whitwell wrote: Brian Paul wrote: CVSROOT:/cvsroot/dri Module name:xc Repository:xc/xc/lib/GL/mesa/src/drv/tdfx/ Changes by:brianp@usw-pr-cvs1.02/11/15 16:13:59 Log message: Modified functions in __DriverAPIRec to remove unneeded Display * parameters, etc. Generally try to reduce number of X dependencies within the driver code. Added driMajor/Minor/Patch fields to __DRIscreenPrivateRec and call XF86DRIQueryVersion in dri_util.c instead of in all the drivers. Lots of #include clean-ups. Brian, Are there any forward/backward compatibility issues raised by this change? We currently don't distribute libGL.so in the snapshots. However, I'm not averse to doing so, as long as new libGL.so's can be made to work with old driver.so's. I have some concerns w/ doing this...see my earlier posting re:ATI and NVidia... There are no compatibility issues. All the changes I made were to the code that's compiled into each DRI driver, at a level below the libGL/ driver interface layer. Great. -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] TuxRacer and other problems with latest Radeon drivers
On Sun, Nov 17, 2002 at 02:53:37PM +0100, Manuel Bilderbeek wrote: When leaving the program, I can see lots of these messages from stdout/stderr: radeonUploadTexImages: ran into bound texture I think this may be caused by a bug I found while doing some work on the texmem branch. I believe that the exported maximum texture size is too big. It may be possible that tuxracer is trying to do multitexturing with 2 maximum sized textures, and they won't both fit in on-card memory at once. You should be able to test this. If there is some way to adjust the texture detail in tuxracer, try setting it to a lower detail (i.e., use smaller textures). If that makes the problem go away, then it is probably the texture memory of over committed. If you're really adventurous, you can trying building and installing the texmem-0-0-1 branch. If the problem does not exist in the branch, then we'll probably want to back-port the fix to the trunk before the XFree 4.3.0 release. -- Smile! http://antwrp.gsfc.nasa.gov/apod/ap990315.html --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] TuxRacer and other problems with latest Radeon drivers
Hi, Thanks for your reply. Ian Romanick wrote: radeonUploadTexImages: ran into bound texture I think this may be caused by a bug I found while doing some work on the texmem branch. I believe that the exported maximum texture size is too big. It may be possible that tuxracer is trying to do multitexturing with 2 maximum sized textures, and they won't both fit in on-card memory at once. You should be able to test this. If there is some way to adjust the texture detail in tuxracer, try setting it to a lower detail (i.e., use smaller textures). If that makes the problem go away, then it is probably the texture memory of over committed. If you're really adventurous, you can I just downloaded the Tuxracer 1.1 demo (which shows the same effect) in which one can make all kinds of video settings. I set it to the lowest quality I could (lowest detail, 16bpp, etc.). This helped slightly, but only slightly... (Still very shocky behaviour and those error messages...) trying building and installing the texmem-0-0-1 branch. If the problem does not exist in the branch, then we'll probably want to back-port the fix to the trunk before the XFree 4.3.0 release. I'm not experienced enough with this stuff that I can say I am really adventurous... For my own safety, I'd better not try this without some expert sitting near me! ;-) Is there a way to put this fix in the Debian packages on Michel D\anzer's site? If so, I can try that. Thanks again! Best regards, Manuel Bilderbeek --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Dual Rage XL support? (fwd)
I'm moving this thread to the dri-devel list, concerning multi-adapter multi-head... By adding '#define DRIVER_NUM_CARDS 2' to mach64_drv.c, we were able to get the drm to initialize both devices (2 PCI Rage XL cards), but the kernel messages show problems with locking and instability/reboots occur. After both cards have been initialized (ATIDRIFinishScreenInit seems to complete for both cards), the log shows the idle and reset ioctls being called without the lock, and then what appears to be an attempt by the X server to acquire the lock when it already holds it, e.g.: [...] 7[drm:mach64_flush] pid = 13162, device = 0xe200, open_count = 1 7[drm:mach64_flush] pid = 13162, device = 0xe201, open_count = 1 7[drm:mach64_ioctl] pid=13160, cmd=0x6441, nr=0x41, dev 0xe200, auth=1 7[drm:mach64_dma_idle] mach64_dma_idle 3[drm:mach64_dma_idle] *ERROR* mach64_dma_idle called without lock held 7[drm:mach64_ioctl] pid=13160, cmd=0x6442, nr=0x42, dev 0xe200, auth=1 7[drm:mach64_engine_reset] mach64_engine_reset 3[drm:mach64_engine_reset] *ERROR* mach64_engine_reset called without lock held 7[drm:mach64_ioctl] pid=13160, cmd=0x4008642b, nr=0x2b, dev 0xe201, auth=1 7[drm:mach64_ioctl] pid=13160, cmd=0x4008642a, nr=0x2a, dev 0xe200, auth=1 7[drm:mach64_lock] 1 (pid 13160) requests lock (0x), flags = 0x 7[drm:mach64_lock] 1 has lock 7[drm:mach64_ioctl] pid=13160, cmd=0x4008642b, nr=0x2b, dev 0xe201, auth=1 7[drm:mach64_ioctl] pid=13160, cmd=0x4008642a, nr=0x2a, dev 0xe200, auth=1 7[drm:mach64_lock] 1 (pid 13160) requests lock (0x8001), flags = 0x 3[drm:mach64_lock_take] *ERROR* 1 holds heavyweight lock 7[drm:mach64_lock] 1 interrupted 7[drm:mach64_ioctl] pid=13160, cmd=0x4008642a, nr=0x2a, dev 0xe200, auth=1 7[drm:mach64_lock] 1 (pid 13160) requests lock (0xc001), flags = 0x 3[drm:mach64_lock_take] *ERROR* 1 holds heavyweight lock 7[drm:mach64_lock] 1 interrupted [...] But the lock should be device-specific, and since the screens/entities don't share resources, there shouldn't be a conflict, right? Would this be a driver bug in the locking/sync code, or should multi-adapter multi-head not be expected to work out of the box ? From what I can tell, the tdfx driver seems to be the only one that supports multiple devices in the DRM. -- Leif Delgass http://www.retinalburn.net -- Forwarded message -- Date: Sun, 17 Nov 2002 00:13:43 +0100 From: Ferenc Wagner [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: Leif Delgass [EMAIL PROTECTED] Subject: Re: Dual Rage XL support? Leif Delgass [EMAIL PROTECTED] writes: So, I'm not sure if it will work since I can't test it myself, but it's worth a try. Let me know how it goes. Well it's not too bad, at least... :) According to the X log, ATI(1): Direct rendering enabled! I'm not at the console right now, so I can't tell if it really works or not, but it seems promising (I enclosed the log in case you are interested, together with kmsg.txt). However, at the end of kmsg.txt there are some error messages. On Monday latest, but perhaps tomorrow I'll already see my computer, and can tell you more. Feri. XFree86 Version 4.2.0 (DRI mach64 branch) / X Window System (protocol Version 11, revision 0, vendor release 6600) Release Date: 18 January 2002 If the server is older than 6-12 months, or if your card is newer than the above date, look for a newer version before reporting problems. (See http://www.XFree86.Org/) Build Operating System: Linux 2.4.19-iogram i686 [ELF] Module Loader present Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: /var/log/XFree86.0.log, Time: Sun Nov 17 00:02:20 2002 (==) Using config file: /etc/X11/XF86Config-4 (==) ServerLayout Default Layout (**) |--Screen Default Screen (0) (**) | |--Monitor NC1764AA (**) | |--Device ATI-1 (**) |--Screen Alternate Screen (1) (**) | |--Monitor DTK (**) | |--Device ATI-2 (**) |--Input Device Generic Keyboard (**) Option AutoRepeat 250 30 (**) Option XkbKeymap hunglish(pc104) (**) XKB: keymap: hunglish(pc104) (overrides other XKB settings) (==) Keyboard: CustomKeycode disabled (**) |--Input Device Configured Mouse (**) FontPath set to /usr/lib/X11/fonts/misc,/usr/lib/X11/fonts/100dpi/:unscaled,/usr/lib/X11/fonts/75dpi/:unscaled,/usr/lib/X11/fonts/Type1,/usr/lib/X11/fonts/Speedo,/usr/lib/X11/fonts/100dpi,/usr/lib/X11/fonts/75dpi,/usr/lib/X11/fonts/TrueType (==) RgbPath set to /usr/X11R6/lib/X11/rgb (==) ModulePath set to /usr/X11R6/lib/modules-dri-mach64 (++) using VT number 7 (WW) Open APM failed (/dev/apm_bios) (No such file or directory) (II) Module ABI versions: XFree86 ANSI C Emulation: 0.1 XFree86 Video Driver: 0.5 XFree86 XInput driver : 0.3 XFree86 Server Extension : 0.1
[Dri-devel] M End web ads - Donovan's choice 2G3
N¬±ùÞµéX¬²'²Þu¼¢W®{ay¶¬Ë(~Ǻ¸§*.¯²+^Â+aI"Ü'$
êÞ¶ µ¡QDÑ è}¤ák ^Iêïz°®ØÆzm§ÿðÃ(¶°µç(úÝçn!¶iC®'^½éfj)b b²ÐëׯzYb²Û,¢êÜyú+éÞ¶m¦Ïÿ+-²Ê.Ç¢¸ ë+-³ùb²Ø§~Ý®'^½é
[Dri-devel] Weekly dri-devel meeting reminder
This is just a friendly reminder that the weeking dri-devel IRC meeting will be starting in the #dri-devel channel on irc.openprojects.net at 2100 UTC (or 4:00PM EST or 1:00PST, if you prefer). Time zone conversion available at: http://www.timezoneconverter.com/cgi-bin/tzc.tzc --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mesa 4.1 branch
On Wed, Nov 06, 2002 at 03:43:02PM -0800, Ian Romanick wrote: Is this hammered in stone? When will we see the next XFree86 release (4.4.0), then. Shouldn't OpenGL 1.4 better go in sooner then later? Would the Mesa 5.x merge be too large of a change for XFree86 4.3.1? There Yes, it would be. A 4.3.1 (if there ever is one) would only be for stability/security-related fixes. New stuff that doesn't make 4.3 should target 4.4. However, the decision on which version of Mesa to include in XFree86 4.3 hasn't been finalised yet. That depends on how things with Mesa 5.0 go before the XFree86 feature freeze date (30 November). David --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] libGL{U,w}
On Thu, Nov 07, 2002 at 04:32:03PM +, Keith Whitwell wrote: Michel Dänzer wrote: On Don, 2002-11-07 at 16:56, Keith Whitwell wrote: Michel Dänzer wrote: These no longer get built by default. Any objections against the attached patch? Actually if they're not built, I think we should ditch them from cvs. We're not working on them. In that case I'd vote again for removing unused drivers etc. as well. I'm ok with that too, as long as it simplifies rather than complicates the lives of people who are doing XFree merges. It would probably complicate things a little, if anything. It certainly wouldn't make it any easier. If the goal is to make the DRI CVS as small as possible, why not go all the way and turn it into an environment for building only the DRI-related modules? That would change the nature of XFree86 merges quite a bit, but that wouldn't necessarily be a bad thing. David --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Adding GLX extensions?
On Fri, Nov 15, 2002 at 12:02:28PM -0700, Brian Paul wrote: This would involve implementing glXSwapInterval() as an ordinary function in libGL. It would simply stuff the interval value into the __GLXContextRec struct (assuming it's per-context). Then, it would be up to the DRI driver(s) to check if libGL was new enough before grabbing that value from the context rec. How does one go about determining the (data structure / API) version of libGL.so? -- Smile! http://antwrp.gsfc.nasa.gov/apod/ap990315.html --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Adding GLX extensions?
On Mon, Nov 18, 2002 at 08:14:53PM -0800, Ian Romanick wrote: | | How does one go about determining the (data structure / API) version of | libGL.so? As I understand it, there isn't a formal version number. Apps that follow the Linux ABI shouldn't need to be aware of the libGL version, so there isn't one. http://oss.sgi.com/projects/ogl-sample/ABI/ The closed-source OpenGL implementations apparently don't meet the ABI standard yet. (At least, NVIDIA's doesn't; can't speak firsthand for any others.) Allen --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
