Re: R300 DRI report
Vladimir Dergachev wrote: You could also try FlightGear as far as games go. Yep, this had been proven to trigger even the obscurest bug during the emergence of the r200 driver ;-) Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R300 success stories
Hello, Adam K Kirchhoff wrote: These are the games I've tried with the latest CVS from this afternoon: [...] Frankly, I'm thrilled at the handful of games that are now working! Those who are looking for additional stress-test cases for OpenGL- (especially R300-, I don't have one myself) drivers, might take notice of this ready-to-run FlightGear package in: ftp://ftp.uni-duisburg.de/FlightGear/Devel/FGBenchmark-0.0.5.tar.gz (approx 76 MByte). The package includes binaries for IRIX/MIPS, Solaris/Sparc, Linux/x86 and FreeBSD-5.x/x86, a README is there as well: ftp://ftp.uni-duisburg.de/FlightGear/Devel/FGBenchmark.README This is, how the picture should look like after startup: http://document.ihg.uni-duisburg.de/bitmap/FGFS/KSFO-startup_01.jpg Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] Doom3 works on R200!
Vladimir Dergachev wrote: What could work, however, is to make a *board* that is capable of decent 3d. Put lots of memory, lots of bandwidth and several DSP to approximate the same level of raw floating-point power as 3d GPUs. Leave everything else to the software. This reminds me of TIGA some years ago. They had X servers running mostly on the graphics board, X libraries actually provided merely the interface to the board's API, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] new API/DRM/fb discsusion..
Vladimir Dergachev wrote: Also, I would venture an opinion that, at the moment, the only Unices we care about is Linux, BSD and Hurd - all open source. The current design of XFree86 (with everything done in userspace) was motivated by the need to support commercial Unices (like Solaris or Unixware). Ooops, is it true that support for Solaris is supposed to be dropped ? Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Gains from doing 2D drawing using OpenGL/mesa
Martin Spott wrote: Alex Deucher wrote: I don't know about that. I can forsee IGP becoming _the_ standard method for video. Look at sgi... all of their video systems use system memory, [...] Really ? Which one ? I know the O2 does, but MGRAS and VPro ? I'm not absolutely sure but I assume they have memory on their respective graphic boards, at least they have texture memory, Obviously SGI changed the direction. The VPro graphic boards for Octane2 and up do have 'real' RAM onboard which is _partially_ used for textures, Martin. P.S.: http://sgistuff.g-lenerz.de/hardware/graphics/vpro.html -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek For a limited time only, get FREE Ground shipping on all orders of $35 or more. Hurry up and shop folks, this offer expires April 30th! http://www.thinkgeek.com/freeshipping/?cpg=12297 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Gains from doing 2D drawing using OpenGL/mesa
Alex Deucher wrote: I don't know about that. I can forsee IGP becoming _the_ standard method for video. Look at sgi... all of their video systems use system memory, [...] Really ? Which one ? I know the O2 does, but MGRAS and VPro ? I'm not absolutely sure but I assume they have memory on their respective graphic boards, at least they have texture memory, Martin (writing this posting on an Octane MXI whose TRAM is definitely too small :-) -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek For a limited time only, get FREE Ground shipping on all orders of $35 or more. Hurry up and shop folks, this offer expires April 30th! http://www.thinkgeek.com/freeshipping/?cpg=12297 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Gains from doing 2D drawing using OpenGL/mesa
Alex Deucher wrote: --- Martin Spott [EMAIL PROTECTED] wrote: Really ? Which one ? I know the O2 does, but MGRAS and VPro ? I'm not absolutely sure but I assume they have memory on their respective graphic boards, at least they have texture memory, I though they used system ram for everything but textures... I could be wrong though. Whooops, I'm very surprised but I assume you're right. There are too few memory-like looking chips on the MXI board to make a useful amount of video RAM, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek For a limited time only, get FREE Ground shipping on all orders of $35 or more. Hurry up and shop folks, this offer expires April 30th! http://www.thinkgeek.com/freeshipping/?cpg=12297 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] New DRI driver interface (Re: CVS Update: xc (branch:
Ian Romanick [EMAIL PROTECTED] wrote: 3. After some testing and cool down period, merge the branch into the trunk. I expect this to happen fairly quickly. In-progress. Please test this branch! :) Would I notice any difference on a non-r200 card or do your changes affect r200 only ? Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356alloc_id=3438op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] New DRI driver interface (Re: CVS Update: xc (branch:
Ian Romanick [EMAIL PROTECTED] wrote: It looks like I should be able to convert the MGA driver today, but I can't make any guarantees. I'd prefer the 'radeon' driver, because I gave my r200 card to my friend ;-) Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356alloc_id=3438op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRI newmesa merge
David D. Hagood [EMAIL PROTECTED] wrote: Felix Kühling wrote: It would be annoying for people with dialup connections if make required access to a remote CVS repository. And how would that be any different than syncing up with the main DRI CVS repo? If you are building one from CVS, you may as well get the other from CVS as well. You would sync manually and not every time you call 'make', Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Adding hardware detection to DRI drivers
Ville Syrj?l? [EMAIL PROTECTED] wrote: On Wed, Oct 15, 2003 at 03:48:38PM -0700, Alex Deucher wrote: there's also this driver: http://www.instmath.rwth-aachen.de:8000/linux/G450-PCI/ I'm not sure how the G4/550 and G200 differ in regard to PCI vs. AGP... AFAIK G450 PCI cards have an AGP-PCI bridge on the card which could do address translation just like the AGP GART. G200/G400 don't have that bridge. I'm not sure if the agpgart driver in that link you posted uses that bridge or some generic PCI GART stuff available on some architectures. Hey, the guy's a good friend of mine - but he never told me he was tweaking DRI stuff I'm pretty shure he wrote the driver for use on his UP2000 Alpha mainboard he used for visualization purpose, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Major mergedFB rework committed to CVS
Alex Deucher [EMAIL PROTECTED] wrote: I can switch back to the old order in the mean time, however, I'm not sure if it is any more or less reliable than the current code. both work fine on my hardware. I just rebuilt the stuff with a CVS checkout from one hour before now. When I do _not_ explicitly _disable_ MergedFB in XG86Config, the X server spits out this to the log: (II) RADEON(0): Generating MergedFB mode list (II) RADEON(0): No MetaModes given, linking first modes by default (EE) RADEON(0): Failed to parse MetaModes or no modes found. MergeFB mode disabled. (--) RADEON(0): MergedFB: Virtual width 1152 (--) RADEON(0): MergedFB: Virtual height 864 This is exactly the resolution that I expect on my one and only screen of a Radeon7500 - but it does not show up, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Adding hardware detection to DRI drivers
On Thu, Oct 16, 2003 at 06:30:53AM -0700, Alex Deucher wrote: Would he be interested in contributing his work back? or maybe explaining how/if he got it working? I'll ask him - he moved to southern Germany earlier this year, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Adding hardware detection to DRI drivers
Alex Deucher [EMAIL PROTECTED] wrote: Would he be interested in contributing his work back? or maybe explaining how/if he got it working? Sorry, currently he's forced to finish his dissertation. He says you might have to wait at least a month until he'll be able to deal with that, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Major mergedFB rework committed to CVS
Alex Deucher [EMAIL PROTECTED] wrote: I just committed a major rework of mergedfb to CVS. almost all of the code is now in radeon_mergedfb.c/h. I also committed Hui's latest code drop from xfree86 CVS. Let me know if anyone has any problems. I'm fine with running the 'new' X server _modules_ with a previously built XFree86 binary when I install the new stuff without restarting the X server I'm currently using. Unfortunately the 'new' X server core binary fails to run at my default resolution [EMAIL PROTECTED] Hz but falls back to 1024x768 at somewhat around 60 Hz (usual effects of too low refresh rate). 'xdpyinfo' fails to print the _real_ parameters: name of display:quickstep.plesnik.bonsai.de:0.0 version number:11.0 vendor string:The XFree86 Project, Inc vendor release number:40399012 XFree86 version: 4.3.99.12 maximum request size: 16777212 bytes motion buffer size: 256 bitmap unit, bit order, padding:32, LSBFirst, 32 image byte order:LSBFirst number of supported pixmap formats:7 supported pixmap formats: [...] default screen number:0 number of screens:1 screen #0: dimensions:1152x864 pixels (361x271 millimeters) This is _definitely wrong !!! resolution:81x81 dots per inch depths (7):16, 1, 4, 8, 15, 24, 32 root window id:0x48 depth of root window:16 planes [...] The effect appears with 24 bpp as well. There is _not_ virtual resolution defined and I did not change my XF86Config since september, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Video Memory Corruption
Chris Ison [EMAIL PROTECTED] wrote: --Boundary_(ID_KcARw6HFWym7RIWbxkMyIg) Content-type: text/plain Content-transfer-encoding: 7BIT can someome please tell me whats causing the video corruption in the attached png image, and explain how to fix it. I'd say the main bug is _YOU_ posting a 3/4 MByte image to a mailing list ! Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Major mergedFB rework committed to CVS
On Mon, Oct 13, 2003 at 06:56:32AM -0700, Alex Deucher wrote: Can you clarify what you tried and what the problem is? When I restart the 'new' (with MergedFB) XFree86 X server binary with the old XF86Config (attached) I get a flickering screen with a resolution that is obviously below what I usually set - but 'xdpyinfo' displays the parameters that I usually expect (but are not present). I attached the X server log file '.0' with flickering screen and Option MergedFB false '.1' with this option put into the XF86Config, which clears the situation for me ! Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- XF86Config.bz2 Description: Binary data XFree86.0.log.bz2 Description: Binary data XFree86.1.log.bz2 Description: Binary data
Re: [Dri-devel] config branch merge schedule
Jos? Fonseca [EMAIL PROTECTED] wrote: Anyway, I'm now building a snapshot. If it succeeds please do a public request for testing on the dri-users and dri-devel. probably combined with a short list of common pitfalls ? Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- 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] FlightGear test with recent CVS
I just did a small test with FlightGear against the recent CVS checkout from freedesktop and I'm delighted. Everything works as expected, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- 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] FlightGear test with recent CVS
Martin Spott [EMAIL PROTECTED] wrote: I just did a small test with FlightGear against the recent CVS checkout from freedesktop and I'm delighted. Everything works as expected, I forgot to mention, that I'm running stock DRM kernel modules from Linux-2.6.0-test5 (Radeon7500), Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- 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] XFree86 merge
Alan Hourihane [EMAIL PROTECTED] wrote: But I also tagged it before starting, so if someone wants to branch for a stable tree you can do it off the trunk-20030912 tag. Did this already happen on 'freedesktop.org' or still on SF ? Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- 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: CVS Update: xc (branch: trunk)
Eric Anholt [EMAIL PROTECTED] wrote: If anyone wants to test, [...] Which video card would you recommend for trying ? I'd see if I can get one, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- 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 error
Keith Whitwell [EMAIL PROTECTED] wrote: Martin Spott wrote: I'm running a quite up-to-date mirror in Germany - currently without public access, but we could change this. Though this mirror suffers from absence of the SF server too What sort of a mirror, Martin? I did a daily CVS update of the CVS trunk in the morning (in Europe, when US citicens usually are gone to bed) - until today. I noticed that it takes the SF server much more than 12 hours to respond to a anonymous CVS update. Now I've switched over to simply duplicate Jose's RSYNC-mirror. Today I started offering this via anonymous rsync. For people like me that don't commit but simply follow the development and test it against their favourite application this is entirely sufficient (at least _I_ think so). This means: Functionality is way reduced compared to CVS/BK/whatever but it might serve to reduce the load on Jose's server. I'm running this primarily for my own purpose but you may have a try if you like. Please note that this server is connected over a 34 MBit/s (beam-) radio link so it might be not _that_ fast : rsync://document.ihg.uni-duisburg.de/DRI_HEAD/ Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- 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: [OT] Sourceforge CVS
Larry McVoy [EMAIL PROTECTED] wrote: On Wed, Sep 03, 2003 at 02:17:19PM +0100, Alan Cox wrote: On Maw, 2003-09-02 at 19:42, Jon Smirl wrote: There are 31 people with write access to dri.sf.net. The simplest solution would be for those 31 to switch to BitKeeper. If thos 31 are OK with that then it's easy, we can do a BK to CVS exporter and the BK people are happy and the CVS people are happy. [ ... and later ...] Larry McVoy [EMAIL PROTECTED] wrote: On Wed, Sep 03, 2003 at 12:59:43PM +0200, Michel D?nzer wrote: On Tue, 2003-09-02 at 23:57, Jon Smirl wrote: -- Michel Dnzer [EMAIL PROTECTED] wrote: I have been using both for a year and BK is simply much better than CVS. I know bk is the best version control system in the universe feature-wise, no need to say it again. And again. And again. (And again) I still don't want to use it. I'm not sure that anyone is asking you to use it. What's wrong with the people who want to use BK use BK and the people who want to use CVS use CVS? [ ] Larry has a clue who he's talking to !?! Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- 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: [OT] Sourceforge CVS
Larry McVoy [EMAIL PROTECTED] wrote: People claim that our license is a problem but the only real problem is the people making the noise. [...] Things are getting ridiculous when you start to superimpose your attitude towards ethics on others - especially when you are obviously lacking the understanding for those people's motivations, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- 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: [OT] Sourceforge CVS
Chris Ison [EMAIL PROTECTED] wrote: DRI is still quite young and alot of people still have the Screw you Billy Goat attitude, [...] Please remember that DRI is not Linux, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- 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 error
Thomas Emmel [EMAIL PROTECTED] wrote: and this message means that the CVS-server is full. I think this was mentioned before two days ago. Some days before I had the problem that the download hangs in xc/xc/util/patch infinitely. Now I tried to download completely from scratch without success. I'm running a quite up-to-date mirror in Germany - currently without public access, but we could change this. Though this mirror suffers from absence of the SF server too Interest ? Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- 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-patches] CVS Update: xc (branch: trunk)
Martin Spott [EMAIL PROTECTED] wrote:
Ian Romanick [EMAIL PROTECTED] wrote:
CVSROOT: /cvsroot/dri
Module name: xc
Repository: xc/xc/programs/Xserver/hw/xfree86/drivers/ati/
Changes by: [EMAIL PROTECTED] 03/08/08 13:34:08
Log message:
Removed the R{ADEON,200}_AGP_TEX_OFFSET contant as it's not really a
constant. Replaced it with a query of a chip configuration register
to get the correct value. This fixes various AGP texturing related
problems on R100 and cleans up a hard-coded constant in the R200 driver.
'Unfortunately' I'm on holiday at the moment. I'll check your changes
against FlightGear as soon as I'm back at work,
I see, tons of updates during the last three weeks. As an owner of a
Radeon9100 I'm _really_ happy with the progress the DRI tree made and I'd
like to thank everyone who participated in this effort (Ian, Felix, Michel,
I didn't remember all the names mentioned in the changelogs),
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--
---
This SF.net email is sponsored by: VM Ware
With VMware you can run multiple operating systems on a single machine.
WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines
at the same time. Free trial click here:http://www.vmware.com/wl/offer/358/0
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
Ian Romanick [EMAIL PROTECTED] wrote:
CVSROOT: /cvsroot/dri
Module name: xc
Repository: xc/xc/programs/Xserver/hw/xfree86/drivers/ati/
Changes by: [EMAIL PROTECTED] 03/08/08 13:34:08
Log message:
Removed the R{ADEON,200}_AGP_TEX_OFFSET contant as it's not really a
constant. Replaced it with a query of a chip configuration register
to get the correct value. This fixes various AGP texturing related
problems on R100 and cleans up a hard-coded constant in the R200 driver.
'Unfortunately' I'm on holiday at the moment. I'll check your changes
against FlightGear as soon as I'm back at work,
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--
---
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
Michel Daenzer [EMAIL PROTECTED] wrote: CVSROOT: /cvsroot/dri Module name: xc Repository: xc/xc/programs/Xserver/hw/xfree86/os-support/shared/drm/kernel/ Changes by: [EMAIL PROTECTED] 03/07/29 03:11:48 Log message: * IRQ code cleanup suggested by Linus Torvalds * i830 build fix BTW, has the discussion on moving the CVS repository finally faded out ? I can't test Michael's modification because I can't pull it from CVS, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Congratulations to recent changes
Currently I don't know _what_ has been changed because ATM I don't have access to the mailing list. But there _must_ have been substantial changes because apparently the too dark lightning with TCL on Radeon bug has been fixed. Running FlightGear on a Radeon9100 with the R200 driver I can't tell the difference beween disabling and enabling TCL any more. Obviously this is a change that happened in the X server modules because I didn't recompile the kernel modules yet. Thanks (I hope the good news don't rely on some sort of 'accident' ;-) Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] searching for other CVS or RSYNC mirror of DRI trunk
Martin Zimmermann [EMAIL PROTECTED] wrote: Maybe we can collect a list of all known and maybe tested mirror pages ... and repost on [EMAIL PROTECTED] 1. rsync -avz --delete rsync://mefriss1.swan.ac.uk/dri/HEAD/ HEAD/ 2. I'm currently trying to collect experience on how reliable I can manage to keep a mirror up to date. I assume that as long as I update the mirror via CVS I still suffer from SF's 24 h lag !? Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- This SF.net email is sponsored by: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here: http://www.vmware.com/wl/offer/345/0 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] radeon 9200 tester available
Rupert Levene [EMAIL PROTECTED] wrote: On Thu, Jul 03, 2003 at 01:07:28AM +0200, Michel Dänzer wrote: PS: http://levene.dyndns.org/invisible-text/normal.png does show a driver problem - the lighting is wrong with HW TCL - but you didn't report that... ;) Well I'd assumed that _this_ was a software problem since it's a new in the latest version =) Is this a known driver problem? If the scene looks to be too dark, then you can assume it's a driver problem. This also shows up in other applications (FlightGear for example). If anyone out ther knows both apps in details it might be interesting to know what the both have in common ;-) Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- This SF.Net email sponsored by: Parasoft Error proof Web apps, automate testing more. Download eval WebKing and get a free book. www.parasoft.com/bulletproofapps ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Only normal DRI and Mesa CVS access as developer, now?
Jos? Fonseca [EMAIL PROTECTED] wrote: If not then the solution would imply moving the CVS repository to a new machine, but where would that be? XFree86.org? Some SF look-a-like? As far as I know BerliOS is hosting quite a few OpenSource projects. This is intended to be some SF alternative. I might not be up to date, but it shurely is worth a look: http://www.berlios.de/index.php.en Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- This SF.Net email is sponsored by: INetU Attention Web Developers Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Torque Engine causes machine lockup on radeon mobility M7
Zik Saleeba [EMAIL PROTECTED] wrote: Running the Torque Engine example application (http://www.garagegames.com/) runs for a few frames and then locks the system up. X is completely hung and it can't be killed. Remote logins to the machine are possible but the display is frozen until reboot. You probably have triggered the same bug that people already experienced with FlightGear - for example. This bug has been somewhat hidden after other (unrelated) improvements (some buffer size reductions for example) but obviously it's still there. I FlightGear it used to show up with or without TCL, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- This SF.Net email is sponsored by: INetU Attention Web Developers Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] CVS Update: xc (branch: trunk)
Hello Jose (I don't know how to type the accent on my keyboard), On Sun, Jun 15, 2003 at 09:21:18PM +0200, Martin Spott wrote: I'll redo the debug output on monday - just to make shure I did not make any mistake. I'm doing this with an OEM Radeon9100. Unfortunately I gave away my Radeon7500 so I don't have any different test case, This is what I have to offer today. This time I reloaded 'radeon' _and_ 'agpgart' kernel module. Afterwards I'm simply starting the X server without running any additional OpenGL program (no X session at all). Today's kernel modules include the recent changes to DRI CVS you added this weekend (taken from the patch called 'drm-really-agp.diff'). Note: I've applied the patches drm_agp-debug.diff, drm_agp-debug2.diff and drm-really-agp.diff to my kernel tree only as I don't believe that the DRI drivers refer to these headers. The rest of the DRI stuff is compiled from a source tree _without_ these patches. Does this matter in any way ? Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- messages.gz Description: application/gunzip
Re: [Dri-devel] CVS Update: xc (branch: trunk)
On Mon, Jun 16, 2003 at 11:46:43AM +0100, José Fonseca wrote: And everything else looks normal - the AGP seems to be alive and kicking. Do you still get direct rendering: No in glxinfo or AGP not available in /var/log/messages ? Yep: 1.) /var/log/XFree86.0.log tells me (II) RADEON(0): [drm] created radeon driver at busid PCI:1:0:0 (II) RADEON(0): [drm] added 8192 byte SAREA at 0xe0c7 (II) RADEON(0): [drm] mapped SAREA 0xe0c7 to 0x40023000 (II) RADEON(0): [drm] framebuffer handle = 0xd800 (II) RADEON(0): [drm] added 1 reserved context for kernel (WW) RADEON(0): [agp] AGP not available (II) RADEON(0): [drm] removed 1 reserved context for kernel (II) RADEON(0): [drm] unmapping 8192 bytes of SAREA 0xe0c7 at 0x40023000 (II) RADEON(0): Memory manager initialized to (0,0) (1152,8191) (II) RADEON(0): Reserved area from (0,864) to (1152,866) (II) RADEON(0): Largest offscreen area available: 1152 x 7325 (II) RADEON(0): Acceleration enabled (II) RADEON(0): Using hardware cursor (scanline 866) (II) RADEON(0): Largest offscreen area available: 1152 x 7321 (II) RADEON(0): Direct rendering disabled 2.) 'glxinfo' still says OpenGL renderer string: Mesa GLX Indirect I really don't know where to look now, so I depend on you/the list for hints what do do to resolve this issue. I'd start by manually backing out the patch from June 4th - or will I run into issues with this attempt ? Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- This SF.NET email is sponsored by: eBay Great deals on office technology -- on eBay now! Click here: http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] CVS Update: xc (branch: trunk)
On Mon, Jun 16, 2003 at 11:46:43AM +0100, José Fonseca wrote: And everything else looks normal - the AGP seems to be alive and kicking. Do you still get direct rendering: No in glxinfo or AGP not available in /var/log/messages ? As I already said: Yes. Now I rebuilt the kernel modules from sources before June 4th and immediately I have HW-Accelerated OpenGL. The 'radeon' kernel module is being linked together from radeon_drv.c radeon_cp.c radeon_state.c radeon_mem.c radeon_irq.c. Unfortunately the mentioned patch touches about a dozend files that that 'radeon' kernel module depends on in one or another way: quickstep: 14:29:11 ~ grep ^\+\+ patches/DRM | wc -l 27 I'd like to collect suggestions where to start ;-)) Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- This SF.NET email is sponsored by: eBay Great deals on office technology -- on eBay now! Click here: http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] CVS Update: xc (branch: trunk)
On Mon, Jun 16, 2003 at 02:31:45PM +0100, José Fonseca wrote: On Mon, Jun 16, 2003 at 01:48:35PM +0200, Martin Spott wrote: (II) RADEON(0): Direct rendering disabled This can't be. This log can't possible match the other one you gave me. In the /var/log/messages it showed the agp buffer being added and so on. The only explanantion I can think of is that you're running _two_ X servers. The first one acquires the AGP device but the second fails to acquire, since the AGP device is already acquired by the first. The explanation sounds reasonable, but I have to disappoint you: There is definitely no second X server running, there also was only one XFree86.0.log because - to make shure not to mix up things - I removed every log that existred previously. How would you explain that the whole scene changes simply by loading a different 'radeon' kernel module ? Let me see, I'll strip down the kernel to only the necessary things and then I'll see if the 'radeon' module collides with anything else. I've attached the DRM patch I'm talking about the whole time. You might compare it with yours to see, if my CVS tree is missing some part. The patch applies against stock 2.4.20 kernel DRM. I can understand that you're somewhat confused. I'll do anything to resolve this issue as my time permits - if you like, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- DRM.gz Description: application/gunzip
Re: [Dri-devel] CVS Update: xc (branch: trunk)
On Mon, Jun 16, 2003 at 03:47:10PM +0200, Martin Spott wrote: I've attached the DRM patch I'm talking about the whole time. You might compare it with yours to see, if my CVS tree is missing some part. The patch applies against stock 2.4.20 kernel DRM. Stupid - sorry for my mistake. This does _not_ apply to stock 2.4.20. The patch is against a kernel that I maintain internally. It should still represent the changes from June 4th, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- This SF.NET email is sponsored by: eBay Great deals on office technology -- on eBay now! Click here: http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] CVS Update: xc (branch: trunk)
Roland Scheidegger [EMAIL PROTECTED] wrote: FWIW, I get that now always when I start the X server, then shut down the X server and start it again. DRI will never work again, unless I rmmod the radeon module manually before I restart the X server. Sounds like some initialization thing. Roland gets the big cookie for reminding me of the thing that never became obvious to me: When I'm preparing for an X session, I'm starting the 'xdm' with an init script and the X server via 'inittab' (-query xdm host). I activate both by entering init runlevel 5. Because of some reason the X server doesn't get a login window on the first attempt, shuts down after XDMCP timeout and gets restarted by 'init'. On the second try the 'xdm' opens a login window, I begin my X session and don't get HW-accelerated OpenGL. _But_, the snippets from XFree86.0.log I sent to this list (Direct rendering disabled) all stem from an X server startup _without_ even trying to contact the 'xdm' - just by typing: # ~ X Return Probably Roland pointed to the right place but the issue still gets triggered in different situations, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- This SF.NET email is sponsored by: eBay Great deals on office technology -- on eBay now! Click here: http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] CVS Update: xc (branch: trunk)
On Sun, Jun 15, 2003 at 07:47:35PM +0100, José Fonseca wrote: Something fishy is going on here. My debug statements never appear in your log and I've just retested on my test box with the latest CVS and everything works as expected with the radeon driver: [...] Martin, are you're sure you're using the right (i.e. the latest) versions of the DRM and 2D drivers? I can't see any other explanation. I am pretty shure they are. They all stem from the same DRI build (they all carry the appropriate date): -r--r--r--1 root root 1342562 Jun 13 15:38 /usr/X11R6/lib/modules/drivers/ati_drv.o -r--r--r--1 root root 3821349 Jun 13 15:38 /usr/X11R6/lib/modules/drivers/atimisc_drv.o -r--r--r--1 root root 13884724 Jun 13 15:36 /usr/X11R6/lib/modules/dri/radeon_dri.so -r--r--r--1 root root 1453282 Jun 13 15:38 /usr/X11R6/lib/modules/drivers/radeon_drv.o lrwxrwxrwx1 root root7 Jun 13 15:38 /usr/X11R6/bin/X - XFree86 -rws--x--x1 root root 18661010 Jun 13 15:38 /usr/X11R6/bin/XFree86 The procedure I use to build the stuff has not differed for quite a few months, absolutely nothing has changed here. I'm getting quite functional binaries when I build the 'radeon' kernel module from sources _before_ the large APG related patch of June 4th and leave _everything_ else untouched. Just to prevent misunderstanding: I have a distribution provided /usr/X11R6/ tree. I take a copy of the current CVS and do a 'make world'. Afterwards I do a 'make install' as root which copies the CVS build _over_ my previous X11R6 tree. Now I generate a patch from the _current_ CVS trees kernel driver sources (.../os-support/[shared,linux]/drm/kernel/*.[h,c] against the sources in /usr/src/linux/drivers/char/drm/*.[h,c] I apply this patch to my kernel tree from which I rebuild and install the kernel modules. This gives me software OpenGL since 4th June. Now I revert the .../os-support/ directory of my CVS tree to a date before June 4th, I generate an appropriate patch against the kernel tree and rebuild the kernel modules. I stop the X server, unload the 'radeon' module by leaving the 'agpgart' module and load the new 'radeon' module from sources before June 4th. Now I have hardware-accelerated OpenGL after restarting the X server. It does not make _any_ difference if I reload _only_ the 'radeon' module, _all_ modules or if I reboot the whole machine. So at least from my point of view it solely depends on the 'radeon' module. I'll redo the debug output on monday - just to make shure I did not make any mistake. I'm doing this with an OEM Radeon9100. Unfortunately I gave away my Radeon7500 so I don't have any different test case, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- This SF.NET email is sponsored by: eBay Great deals on office technology -- on eBay now! Click here: http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] CVS Update: xc (branch: trunk)
Content-Disposition: attachment; filename=drm_agp-debug2.diff I applied both of Jose's patches and loaded the 'radeon' module with drm_opts=debug as suggested my Michel. I attached the compressed debug output from loading the module until X server startup that I found in /var/log/messages. If the attachement does not get through I'd resend it plain test, but it's 18 kByte large, I hope I can help in solving this issue, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- messages.gz Description: application/gunzip
Re: [Dri-devel] CVS Update: xc (branch: trunk)
Martin Spott [EMAIL PROTECTED] wrote: I applied both of Jose's patches and loaded the 'radeon' module with drm_opts=debug as suggested my Michel. I attached the compressed debug output from loading the module until X server startup that I found in /var/log/messages. BTW, I forgot to mention that I had to switch to SuSE-8.2 yesterday which implies the use of GCC-3.3 - fortunately the stuff still build correctly. I hope this does noch touch the meaning of the debug messages, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- This SF.NET email is sponsored by: eBay Great deals on office technology -- on eBay now! Click here: http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] CVS Update: xc (branch: trunk)
Hello Jose,
Since it's easy for you to rebuild the kernel module, try the attached
patch which adds a debug output line. That line should appear, and both
pointers should be non-NULL.
I applied your patch but I did not notice where the expected debug output
should appear. Should it show up on STDERR, in the syslog, in XFree ?
'/var/log/messages' looks as usual on 'radeon' module load and X server
start:
Jun 12 08:19:25 quickstep kernel: [drm] AGP 0.99 aperture @ 0xe400 64MB
Jun 12 08:19:25 quickstep kernel: [drm] Initialized radeon 1.9.0 20020828 on minor 0
Jun 12 08:19:25 quickstep kernel: [drm] Loading R200 Microcode
Jun 12 08:19:28 quickstep kernel: [drm:radeon_cp_init] *ERROR* radeon_cp_init called
without lock held
Jun 12 08:19:28 quickstep kernel: [drm:radeon_unlock] *ERROR* Process 26871 using
kernel context 0
I attached a compressed XFree86.0.log - in case it might be useful (it's
only 8k).
I managed to get something different. When setting LIBGL_DEBUG=verbose, each
time I start a program that is supposed to use OpenGL, I can read the
following on STDERR immediately after hitting enter:
libGL error: XF86DRIQueryDirectRenderingCapable returned falselibGL error:
XF86DRIQueryDirectRenderingCapable returned falselibGL error:
XF86DRIQueryDirectRenderingCapable returned falsename of display:
quickstep.plesnik.bonsai.de:0.0
This _is_ the correct FQDN and ${DISPLAY} is definitely correct - it has
been ever since. The libGL that is used definitely comes from the same
source as the DRM and DRI modules came from,
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--
---
This SF.NET email is sponsored by: eBay
Great deals on office technology -- on eBay now! Click here:
http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] CVS Update: xc (branch: trunk)
On Thu, Jun 12, 2003 at 12:19:17PM +0200, Michel Dänzer wrote:
On Thu, 2003-06-12 at 08:42, Martin Spott wrote:
I applied your patch but I did not notice where the expected debug output
should appear. Should it show up on STDERR, in the syslog, in XFree ?
Wherever kernel output goes, but you'll have to load the DRM with
drm_opts=debug .
Thanks !
You're saying you've always used quickstep.plesnik.bonsai.de:0.0 for
$DISPLAY? That would be a TCP instead of a UNIX socket, not sure the DRI
is supposed to work with that. I use :0.0 .
I'm running 'xdm' standalone. Afterwards I start the X server with
'-query quickstep'. This is how I lernt to know X quite a few years ago and
somtimes I love to stick to old habits ;-)
As far as I know DRI first looks for a valid device behind /dev/dri/card0
on the local filesystem. If it finds one, it does not bother about
${DISPLAY},
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--
---
This SF.NET email is sponsored by: eBay
Great deals on office technology -- on eBay now! Click here:
http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
Jose Fonseca [EMAIL PROTECTED] wrote: CVSROOT: /cvsroot/dri Module name: xc Repository: xc/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/ Changes by: [EMAIL PROTECTED] 03/06/03 16:27:02 Log message: Split declarations/definitions in drm_scatter.h into drm_sg.h/drm_sg_tmp.h respectively. Splited the work out of the ioctls and renamed (with the _ioctl prefix). Added some more documentation. Did the same for drm_sgpsupport.h. Modified files: xc/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/: drmP.h drm_bufs.h drm_drv.h drm_memory.h drm_memory_debug.h gamma_drv.c i810_drv.c i830_drv.c mga_drv.c r128_drv.c radeon_drv.c sis_drv.c Added files: xc/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/: drm_agp.h drm_agp_tmp.h drm_sg.h drm_sg_tmp.h Removed files: xc/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/: drm_agpsupport.h drm_scatter.h As far as I can recover, this is the patch that made DRM unavailable on my system. When I load the appropriate kernel modules (agpgart, radeon) by starting the X server, /var/log/messages writes the following. This is from the current CVS tree, but it read the same before the version change to 1.9.0: Jun 11 18:58:22 quickstep kernel: agpgart: AGP aperture is 64M @ 0xe400 Jun 11 18:58:22 quickstep kernel: [drm] AGP 0.99 aperture @ 0xe400 64MB Jun 11 18:58:22 quickstep kernel: [drm] Initialized radeon 1.9.0 20020828 on minor 0 Jun 11 18:58:23 quickstep kernel: [drm] Loading R200 Microcode Jun 11 18:58:25 quickstep kernel: [drm:radeon_cp_init] *ERROR* radeon_cp_init called without lock held Jun 11 18:58:25 quickstep kernel: [drm:radeon_unlock] *ERROR* Process 12217 using kernel context 0 XFree86.0.log simply writes: [...] drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 7, (OK) drmGetBusid returned '' (II) RADEON(0): [drm] created radeon driver at busid PCI:1:0:0 (II) RADEON(0): [drm] added 8192 byte SAREA at 0xe0cc5000 (II) RADEON(0): [drm] mapped SAREA 0xe0cc5000 to 0x4002 (II) RADEON(0): [drm] framebuffer handle = 0xd800 (II) RADEON(0): [drm] added 1 reserved context for kernel (WW) RADEON(0): [agp] AGP not available (II) RADEON(0): [drm] removed 1 reserved context for kernel (II) RADEON(0): [drm] unmapping 8192 bytes of SAREA 0xe0cc5000 at 0x4002 (II) RADEON(0): Memory manager initialized to (0,0) (1152,8191) (II) RADEON(0): Reserved area from (0,864) to (1152,866) (II) RADEON(0): Largest offscreen area available: 1152 x 7325 (II) RADEON(0): Acceleration enabled (II) RADEON(0): Using hardware cursor (scanline 866) (II) RADEON(0): Largest offscreen area available: 1152 x 7321 (II) RADEON(0): Direct rendering disabled This is on a OEM Radeon9100. What information may I provide to you to fix this ? Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- This SF.NET email is sponsored by: eBay Great deals on office technology -- on eBay now! Click here: http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] [RFC] New Xv adapter using MESA_ycbcr_texture
Matt Sealey [EMAIL PROTECTED] wrote: I'm sure that MPlayer or Xine actually support an OpenGL output plugin already. Chances are it's Xine, but I haven't touched it in 6 months, maybe they removed it? I believe it's still there. Before propagating the use of 'new' API's in Xinre for example please remember that this software was designed to run on other platforms, too, that don't know anything of MESA (IRIX for example). Um.. IRIX doesn't have OpenGL now? That's not what I was claiming. People where talking about 'MESA_ycbcr_texture' which I was referring to (see my posting), Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] [RFC] New Xv adapter using MESA_ycbcr_texture
Matt Sealey [EMAIL PROTECTED] wrote: I'm sure that MPlayer or Xine actually support an OpenGL output plugin already. Chances are it's Xine, but I haven't touched it in 6 months, maybe they removed it? I believe it's still there. Before propagating the use of 'new' API's in Xinre for example please remember that this software was designed to run on other platforms, too, that don't know anything of MESA (IRIX for example). Thanks, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Fresh DRI driver snapshots - call for testers
Jos? Fonseca [EMAIL PROTECTED] wrote: FYI these snapshots were built by checking out the DRI CVS over the XFree86 4.3.0 source [...] This is tough - I didn't think it would work :-) This remembers me of a question that came up recently: Some of the changes that recently were made to the XFree86 CVS repository touch files that are part of the DRI tree. Does anyone track these changes with the intention to update the DRI tree accordingly ? Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- This SF.net email is sponsored by: ValueWeb: Dedicated Hosting for just $79/mo with 500 GB of bandwidth! No other company gives more support or power for your dedicated server http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Fresh DRI driver snapshots - call for testers
On Fri, Apr 04, 2003 at 03:59:16PM +0200, Michel Dänzer wrote: On Fre, 2003-04-04 at 14:56, Martin Spott wrote: This remembers me of a question that came up recently: Some of the changes that recently were made to the XFree86 CVS repository touch files that are part of the DRI tree. Does anyone track these changes with the intention to update the DRI tree accordingly ? Are you thinking of anything in particular? I didn't notice anything but backports of fixes from the DRI tree or cosmetical fixes. Lemme see if I can find the posting quickly Changes by: [EMAIL PROTECTED] 03/04/03 14:47:42 56. Allow AGPGART support to be enabled for OpenBSD (#A.1684, Brian Feldman). [...] 3.11 +2 -2 xc/programs/Xserver/hw/xfree86/os-support/linux/lnx_agp.c Changes by: [EMAIL PROTECTED] 03/04/03 08:38:52 42. Fix memory leaks in ProcXF86VidModeModModeLine and ProcXF86VidModeValidateModeLine, [...] 1.15 +6 -2 xc/programs/Xserver/hw/xfree86/common/xf86VidMode.c Changes by: [EMAIL PROTECTED] 03/04/03 08:16:02 34. Add a new request to the XF86Misc extension that allows a client to send an arbitrary message to the DDX, which in turn can send the message to the driver. [...] 1.92 +10 -1 xc/programs/Xserver/hw/xfree86/drivers/ati/ I'm shure there are some more. I could be wrong but it appears to me that it _might_ me useful to track these changes to minimize the next merge !? I'm not the one who defines how to follow the XFree86 tree, I'm just a bit curious. Or are all these changes already part of the DRI tree ? Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- This SF.net email is sponsored by: ValueWeb: Dedicated Hosting for just $79/mo with 500 GB of bandwidth! No other company gives more support or power for your dedicated server http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] thanks for the XFree-merge
Martin Spott [EMAIL PROTECTED] wrote: Ian Romanick [EMAIL PROTECTED] wrote: I'm going to freeze the texmem-0-0-1 branch and begin the arduous task of merging the trunk. Since I'm not quite as experienced at doing merges as Alan, it will probably take me awhile... It is probably not bad to let Keith's merge settle for a few days (so I have the chance to test it ;-) before the next merge happens, Works excellent for me on a Radeon7500, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- This SF.net email is sponsored by: ValueWeb: Dedicated Hosting for just $79/mo with 500 GB of bandwidth! No other company gives more support or power for your dedicated server http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] thanks for the XFree-merge
I'd like to express my thanks for the merge of XFree86-4.3 and the related work. The current 'trunk' is the most stable and accurate implementation of hw- accelerated OpenGL I've seen on Linux with a Radeon (in my case) for quite some time (as long as you factor out the light position issues with TCL ...) In between I've not only tested different stages of DRI development, I've also tried XiG's Summit-2.2 server on an ES Tornado3k and on two different Radeon boards (original 7500 and OEM 9100, textures in FlightGear look _horrible_). DRI is simply the best ;-) I'm looking forward to see the merges of the branches that are currently floating around (texmem, filp and mach64), Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- This SF.net email is sponsored by: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] thanks for the XFree-merge
Ian Romanick [EMAIL PROTECTED] wrote: Since it appears that the filp work has been merged in to the trunk, [...] Oh, I noticed too late I'm going to freeze the texmem-0-0-1 branch and begin the arduous task of merging the trunk. Since I'm not quite as experienced at doing merges as Alan, it will probably take me awhile... It is probably not bad to let Keith's merge settle for a few days (so I have the chance to test it ;-) before the next merge happens, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- This SF.net email is sponsored by: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] XFree86-4.3 DRI and kernel-2.5.X
Louis Garcia [EMAIL PROTECTED] wrote: Is their anyway I can get a diff for XFree86-4.3 DRI against 2.5.latest? I'm starting to play with this kernel and want dri working for my radeon. Diff against what ? XFree86-4.3.0 should work fine 'out of the box' with Linux-2.5.x. I've already tried that quite a few times. It might be hindering though, that the Radeon DRI driver in current XFree86 might fail in some special cases. You'd better wait until Alan has finished his great work merging the current XFree86 into the DRI tree because Mesa-5.x based DRI in the current DRI trunk is supposed to be much more stable than what is in XFree 4.3 now (as far as I remember from previous tests), Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- This SF.net email is sponsored by: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] 4.3.0 merge
Jens Owen [EMAIL PROTECTED] wrote: Keith Whitwell wrote: Alan Hourihane wrote: I'm going to start the 4.3.0 merge. Be prepared for breakage. I'll post another followup when I'm finished. Thanks for doing this, Alan. Definitely. Thanks, Alan. Oh yes, this way we'll have best of both worlds. I'm sort of happy about this, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- This SF.net email is sponsored by: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [forum] Re: [XFree86] Invitation for public discussion about
Keith Whitwell [EMAIL PROTECTED] wrote: It's always a shock to see that what is meant to tease when written comes out looking more like a direct attack when read back... Oh, I would agree even if it was considered as sort of an attack, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- This SF.net email is sponsored by: Tablet PC. Does your code think in ink? You could win a Tablet PC. Get a free Tablet PC hat just for playing. What are you waiting for? http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [forum] Re: [XFree86] Invitation for public discussion about the future of X
Philip Brown [EMAIL PROTECTED] wrote: Perhaps then, this will provide enough incentive for DRI to move back into a pure extension module form, rather than its current xfree tree entanglement. You don't want to imply that people touch bigger areas as is would be necessary for DRI development - do you !? Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- This SF.net email is sponsored by: Tablet PC. Does your code think in ink? You could win a Tablet PC. Get a free Tablet PC hat just for playing. What are you waiting for? http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Serious Sam: 2nd Edition crash
Michel D?nzer [EMAIL PROTECTED] wrote: The texmem branch doesn't have the FlushVertices fix yet, which seems to help with a number of lockups. Try http://penguinppc.org/~daenzer/DRI/applied/r200-radeon-flushvertices.diff If it does not work, try this one - I never experienced any Radeon-lockup since I recompiled the driver with the patch mentioned here: Changes by: [EMAIL PROTECTED] 03/03/12 05:54:45 Log message: Fix recycle lockup (Michel Danzer) Modified files: xc/xc/programs/Xserver/hw/xfree86/drivers/ati/: Tag: mesa-4-0-4-branch radeon_dri.c Revision ChangesPath 1.37.2.6 +1 -0 xc/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_dri.c Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- 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] Serious Sam: 2nd Edition crash
On Mon, Mar 17, 2003 at 02:41:43PM +0100, Michel Dänzer wrote: On Mon, 2003-03-17 at 14:11, Martin Spott wrote: Michel D?nzer [EMAIL PROTECTED] wrote: Changes by: [EMAIL PROTECTED] 03/03/12 05:54:45 Log message: Fix recycle lockup (Michel Danzer) Modified files: xc/xc/programs/Xserver/hw/xfree86/drivers/ati/: Tag: mesa-4-0-4-branch radeon_dri.c Revision ChangesPath 1.37.2.6 +1 -0 xc/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_dri.c That change only has an effect on a server reset, I have no idea why it would make a difference otherwise. I don't know either _why_ it would - this is beyond my insight into the subject. On the other hand I know that it definitely improves stability of the server on my end, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- 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] Serious Sam: 2nd Edition crash
Michel D?nzer [EMAIL PROTECTED] wrote: You could try to set the environment variables RADEON_NO_CODEGEN, RADEON_NO_VTXFMT and RADEON_TCL_FORCE_DISABLE [...] BTW, I just aquired a Radeon9100 clone to see if serveral 'features' resemble the behaviour I'm used to see on my Radon7500. Infortunately they pretty much behave the same way: The card locks up under certain 'well known' conditions and FlightGear looks quite dark with TCL enabled. I'm now looking for a switch to disable TCL on the r200 based card but grepping the source code I did not find an equivalent to the above mentioned environment setting. Did I miss it ? Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- 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] Serious Sam: 2nd Edition crash
Michel D?nzer [EMAIL PROTECTED] wrote: BTW, are you actually using 4x transfer rate? If so, have you tried lowering it? I't like to note that the lockups I saw with FlightGear and Solace were completely independent from the AGP transfer rate of my Radeon7500. I did quite a few tests to be shure about it. The same applies for the Radeon9100 I tried today, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- 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] Re: [Dri-patches] CVS Update: xc (branch: mesa-4-0-4-branch)
Martin Spott [EMAIL PROTECTED] wrote: Keith Whitwell [EMAIL PROTECTED] wrote: CVSROOT: /cvsroot/dri Module name: xc Repository: xc/xc/programs/Xserver/hw/xfree86/drivers/ati/ Changes by: [EMAIL PROTECTED] 03/03/12 05:54:45 Log message: Fix recycle lockup (Michel Danzer) Modified files: xc/xc/programs/Xserver/hw/xfree86/drivers/ati/:Tag: mesa-4-0-4-branch radeon_dri.c Not bad - this fixes all crash scenarios I had with my Radeon. This makes not only FlightGear run stable but also fixes the freeze with 'Solace' (wildly moving the output window over the screen). Yup, now the Radeon X server survives 5 simultaneous 'glxgears' during startup of 'FlightGear' in the freeze Radeon X server configuration while moving 'Solace' over the screen. Am I the only one who is now happy with the stability of the X server or does anyone have similar experience ? Now the only apparent complication leftover is about 'dark lightning' in FlightGear. At the risk of telling an old tale I'd dare to post some words that I already used to annoy other members of this list ;-) Dieter N?tzel [EMAIL PROTECTED] wrote: Am Dienstag, 4. März 2003 20:17 schrieb Martin Spott: P.S.: There's still the dark lightning issue with FG on Radeon ;-)) Are all your TCL colors right? No, they're still in 'bad shape' (TM). Curt Olson once pointed to a possible bug in the TCL implementation and there are signs he might be right. When I start at 11 AM local time usually the terrain looks properly illuminated. Here you can get an idea how it should look like: http://www.de.flightgear.org/images/j3cub-departing-KNOW.jpg When you enable TCL, take off, bank the plane about 120 degree clockwise (yes, then you're pretty much flying top-down) and watch straight out of the cockpit, then you also see pretty illuminated terrain. How much you have to turn the plane to achieve this depends on the time of day ! I can achieve similar effect by setting the whole terrain to be shining without external light source (like the sun) in FlightGear - even at night, this looks cool ;-) Now Curt suggests that probably the TCL code does not handle the light source (sun) position properly - this would explain why the terrain appears to be shining throuh in certain directions, variying with the time of day. I took a screenshot which probably emphasizes this idea: http://document.ihg.uni-duisburg.de/bitmap/Radeon/Illumination_01.png This is taken at 11 AM local time in April - it looks pretty much the same in August. As you can see the lower right side of the body is well illuminated, even the fillet between the right wing and the body is bright. The terrain instead is hardly illuminated - it looks like the sun to be shining from below the surface, Thanks for your attention, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- 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-patches] CVS Update: xc (branch: mesa-4-0-4-branch)
Keith Whitwell [EMAIL PROTECTED] wrote: CVSROOT: /cvsroot/dri Module name: xc Repository: xc/xc/programs/Xserver/hw/xfree86/drivers/ati/ Changes by: [EMAIL PROTECTED] 03/03/12 05:54:45 Log message: Fix recycle lockup (Michel Danzer) Modified files: xc/xc/programs/Xserver/hw/xfree86/drivers/ati/: Tag: mesa-4-0-4-branch radeon_dri.c Not bad - this fixes all crash scenarios I had with my Radeon. This makes not only FlightGear run stable but also fixes the freeze with 'Solace' (wildly moving the output window over the screen). Thanks, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- 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-patches] CVS Update: xc (branch: trunk)
Michel Daenzer [EMAIL PROTECTED] wrote: CVSROOT: /cvsroot/dri Module name: xc Repository: xc/xc/lib/GL/mesa/src/drv/radeon/ Changes by: [EMAIL PROTECTED] 03/03/03 17:02:35 Log message: Set Mesa hooks to flush vertices on state changes (Keith Whitwell) Whps, it appears to me that this fixes the FlightGear lockups. I did several tries of my usually reliable 'test routine' (starting with a viev straight out of the B747 cockpit) and it did _not_ crash the server until now. I'll try further. If this proves to be real maybe someone should contribute this as a patch against XFree86-4.3-branch ;-) Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
Martin Spott [EMAIL PROTECTED] wrote: Michel Daenzer [EMAIL PROTECTED] wrote: CVSROOT: /cvsroot/dri Module name: xc Repository: xc/xc/lib/GL/mesa/src/drv/radeon/ Changes by: [EMAIL PROTECTED] 03/03/03 17:02:35 Log message: Set Mesa hooks to flush vertices on state changes (Keith Whitwell) Whps, it appears to me that this fixes the FlightGear lockups. This definitely looks to be stable for me so far with a Radeon7500. I'll be out of office for the rest of the week so I could not stress test this under different conditions. I'd be happy if others could confirm the sanitizing effect of these patches. I forgot to mention that I currently run the DRM driver from XFree86-4.3.0, I'll test others next week if anyone is interested. Thanks, Martin. P.S.: There's still the dark lightning issue with FG on Radeon ;-)) -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Remote OpenGL
Philip Brown [EMAIL PROTECTED] wrote: On Sun, Mar 02, 2003 at 10:33:15PM +, Martin Spott wrote: I don't know _why_ this works because you're not using DRI. DRI essentially for Xserver-side stuff. The X server is on the SGI. That's quite clear ;-) DRI is not involved here. You're just using a libGL.so that knows how to talk the GLX extension protocol over the wire. I thought I was 'told' that the libGL that is provided with XFree86 inevitably depends on having DRI as a 'backend' for hardware OpenGL rendering. Obviously I was wrong. P.S.: gcc-3.2.2, glibc-2.3.1, xfree86-3.4.0 *Amazing! ;-) Maybe that's because I was typing while flying. You should not do that :-) Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- 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] Remote OpenGL
Hello, did you know that remote display of OpenGL apps is partially functional with DRI ? At least the client side works ! I'm currently running FlightGear on a Linux PC against an SGI Octane functioning as X terminal. Performance is not bad - at least better than running FlightGear native on the (low speed) Octane :-) I don't know _why_ this works but obviously the OpenGL(/DRI) library provided with XFree86 is able to detect OpenGL support on the server side and does _not_ render in software. This is _really_ nice to see !! Unfortunately from my point of view this affirms the suspicion that the 'dark lightning' issue with FlightGear at least on Radeon is a server-side problem. Running FlightGear against OpenGL libraries compiled from the identical source tree against a DRI based Radeon X server does not look that nice. Running the same stuff against Octane X server instead looks as everyone loves it ;-) Happy, Martin. P.S.: gcc-3.2.2, glibc-2.3.1, xfree86-3.4.0 -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- 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: future of DRI? - why no one plays with Glide3.
Mike A. Harris [EMAIL PROTECTED] wrote: On Sat, 1 Mar 2003, Smitty wrote: Which is probably why Molton is trying to instigate a divorce from Glide for the V3. I certainly support that move. Anholt was working on Glide3 recently a bit as well. I dunno how far he got, but I've been meaning to ask. Ian Molton got a Voodoo3 3k from me but he yet did not manage to have the time for necessary work on that, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- 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] GL image distortions with Radeon VE
Nick Kurshev [EMAIL PROTECTED] wrote: Image distortion became visible in oct 2002. This probably was the time when hardware-TCL came into play !? You could try to set $RADEON_TCL_FORCE_DISABLE to 't' and see if it makes any difference, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- 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] Using DRI to implement 2D X drivers
Michel D?nzer [EMAIL PROTECTED] wrote: The radeon driver uses the DRM for 2D acceleration when DRI is enabled, Is the radeon driver the only one doing so ? Is it possible that heavy simultaneous use of 2D and 3D graphics is responsible for the DRM freezing the X server with FlightGear ? You remember, I get the stuff near to stable as long as FlightGear is the only X client running on the display. This is just a vague assumption, but I thought it might be allowed as long as nobody knows the truth about the X server freezes ;-) Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- 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: [Dri-patches] CVS Update: xc (branch: drm-filp-0-1-branch)
Keith Whitwell [EMAIL PROTECTED] wrote: CVSROOT: /cvsroot/dri Module name: xc Repository: xc/xc/programs/Xserver/hw/xfree86/os-support/shared/drm/kernel/ Changes by: [EMAIL PROTECTED] 03/02/24 19:59:01 Log message: Use file pointers instead of pids for resource and lock tracking [...] quickstep: 19:28:48 /usr/src/linux/drivers/char/drm gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=i686 -DMODULE -DKBUILD_BASENAME=i810_dma -c -o i810_dma.o i810_dma.c i810_dma.c: In function 810_dma_get_buffer': i810_dma.c:245: warning: unused variable riv' i810_dma.c: In function 810_reclaim_buffers': i810_dma.c:909: structure has no member named id' Did I miss something ? Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- This SF.net email is sponsored by: Scholarships for Techies! Can't afford IT training? All 2003 ictp students receive scholarships. Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more. www.ictp.com/training/sourceforge.asp ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon 9000Pro hangs with current DRM
Alan Cox [EMAIL PROTECTED] wrote: I updated the radeon DRM to include the texture upload changes. My radeon hang with flightgear now happens every two hours instead of instantly. Would you please be so kind to try the B747 ? Please run FG with the option: --aircraft=747-yasim When it dies X is stuck, the mouse pointer works. The 3D app is burning a lot of CPU and the system is otherwise running. At the point the 3D is killed (kill -9 etc) the box hangs solid Absolutely the same effect as over here. Unfortunately it gets stuck on startup with the B747, immediately after writing some message like Reading electrical system model from [...], Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- 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] module release method, threads, pids
Felix K?hling [EMAIL PROTECTED] wrote: No idea, just a comment. This reminded me of the famous X hangs when flightgear exits. Recently I read in some posts on the plib-users mailing list that flightgear is multi-threaded, too. The situation is somewhat different, though. There is only one context and AFAIK only one thread uses OpenGL. [...] Right, because Curt Olson obviously knows _very_ well about OpenGL not being thread safe, he almost _prays_ avoiding multiple threads in one rendering context ;-) Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- 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 9000Pro hangs with current DRM
Alan Cox [EMAIL PROTECTED] wrote: With a 747 it starts up, I get a cockpit, I turn up the engines taxi down the runway and embed the nose in the ground. I can't fly a 747 but I don't see the problem you reported Thanks for the test. Maybe we have too look at the differences between a Radeon7500 (mine) and a '9000 Martin. P.S.: It should be easy to get a B747 off the ground, you just have to wait until the runway ends and pull up a few seconds before. It's much more difficult to touchdown right on the runway after flight ;-) -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- 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] Lock problem with Radeon DRI
On Fri, Feb 14, 2003 at 04:51:24PM +, Alan Cox wrote: On Fri, 2003-02-14 at 14:52, Martin Spott wrote: Where did you take the DRM sources from ? I usually take the source for the DRM module from the same DRI CVS tree I use to build the whole DRI thing, Mike Harris builds in Red Hat beta and in rawhide It appears to me that the kernel modules of Mike's build do not differ from XFree86 4.2.99.901 - at least he didn't include any additional patches that thouch the kernel modules. I have the impression he also did not include any patches that touch the Radeon driver in a way that might prevent from lockups. So are we going to see XFree86-4.3.0 with broken Radeon DRI drivers ? Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- 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] Lock problem with Radeon DRI
How can get a new module? Do I have to build XF86 from source No, you don't have to rebuild the whole XFree86. I usually take the Sources from: xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/ xc/programs/Xserver/hw/xfree86/os-support/shared/drm/kernel/ and adjust the Makefile in my kernel tree accordingly. So I just have to 'make modules' in the kernel tree to get updated DRI modules, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- 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] Lock problem with Radeon DRI
On Tue, Feb 18, 2003 at 02:34:29PM -0500, Leif Delgass wrote: On Tue, 18 Feb 2003, Martin Spott wrote: So are we going to see XFree86-4.3.0 with broken Radeon DRI drivers ? I noticed that Michel's fix for large textures in radeon_cp_dispatch_texture() has only been in XFree86 cvs since 4.2.99.902 (about 10 days ago). I'm not sure if the problem that fixed could cause a lockup, [...] No, unfortunately it does not. I am currently running a kernel with DRM built from XFree86-4.2.99.902 and it still locks up reliably. 'radeon_state.c' is identical to the one in DRI trunk. I've already been testing quite a few patches that have been floating around in 'dri-devel' and you would have heard me shouting out loud if one of them would had solved the lockup-issue ;-) Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- 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] MindRover+Radeon+DRI=crash
I wrote that MindRover crashes X with Radeon VE and DRI. Last days I asked few people on irc to test MindRover-demo with their Radeons (TCL and no-TCL, DRI from current CVS and older). All of them got X locked. [...] I'm glad to see that FlightGear is not the only reliable test case for the Radeon X server lockup 'feature' ;-)) Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Lock problem with Radeon DRI
[... Alan Cox wrote ...] On Fri, 2003-02-14 at 13:37, Michel Dänzer wrote: That DRM is pretty old, is the 3D driver from the same date? Someone said on an XFree86 list that the flightgear lockups went away for him with XFree86 4.3.0rc1. My lockup with flightgear on the 9000 with 4.2.99 based tree and a recent DRM module. Where did you take the DRM sources from ? I usually take the source for the DRM module from the same DRI CVS tree I use to build the whole DRI thing, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Lock problem with Radeon DRI
On Fri, Feb 14, 2003 at 04:51:24PM +, Alan Cox wrote: On Fri, 2003-02-14 at 14:52, Martin Spott wrote: My lockup with flightgear on the 9000 with 4.2.99 based tree and a recent DRM module. Where did you take the DRM sources from ? I usually take the source for the DRM module from the same DRI CVS tree I use to build the whole DRI thing, Mike Harris builds in Red Hat beta and in rawhide So if Mike appears to have 'the right stuff' (TM), would it be worth merging the missing bits to the DRI ? I'll see if I can find this stuff and if it helps getting 'my' FlightGear stable, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] [patch] SWTCL vertex data corruption
Can someone commit this? Does this fix *all* the problems? I don't know if it would. It probably fixes SW TCL bugs - as Felix states - but it does not touch the HW TCL related problems with the radeon driver. They still exist, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Flightgear and lighting (WAS: SWTCL vertex data corruption)
On Thu, Feb 13, 2003 at 04:12:46PM +0100, Felix Kühling wrote: On Thu, 13 Feb 2003 15:29:44 +0100 (CET) Martin Spott [EMAIL PROTECTED] wrote: It probably fixes SW TCL bugs - as Felix states - but it does not touch the HW TCL related problems with the radeon driver. They still exist, It would just be too good to be true if there was one simple patch that fixes all problems ;-) As you wrote to me in private mail you are referring to lockup problems and the dark lighting in flightgear. I'd like to add, that the lockups appear definitely _not_ to be TCL related. Maybe this is not new to you, but in case I tried to take some screenshots to document the 'dark lightning' issue for the FlightGear people: I log into my X session, this starts several 'aterm's. In one terminal window I set $RADEON_TCL_FORCE_DISABLE to 't'. In this window I'll start FlightGear afterwards. After FlightGear comes up, I toggle the view (side view is nicer to look at). Now I click into another window to start 'import' (from ImageMagick) to take a screen shot of the correctly coloured FlightGear window. In this moment the 'aterm' has the window focus. When I click on the title bar of my FlightGear window I get back the FlightGear window in foreground but the window does not get the focus back because the X server locks up before. I dont know how many reboots I did to take a single screen shot ;-) Slightly irritated, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mach64-0-0-6-branch
[...] Since the GATOS head is now based on current XFree86 cvs, I may not have a new patch until 4.3.0 is released and changes get propagated back to the DRI and GATOS trees. Could anyone tell me if I'll find recent GATOS stuff merged into the current XFree86-4.3 pre-releases ? I did not find the answer neither on the GATOS pages nor in the XFree86 CVS 'changes.html' document. I _did_ expect XFree86-4.3 to be 'up to date' with GATOS and would like to see some sort of proof - _before_ downloading tons of source code, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Context teardown
There are now two patches, one from Egbert Eich (who reported the problem). I haven't had time to look at his as it changes some deep, dark, dri stuff that I wasn't ever involved with, but looks sane nonetheless. His avoids the error reply from the X server, whereas mine copes with it once it arrives. I'm not sure either will help texobj which seems to be a malloc/free bug. I'm attaching both. I actually think applying *both* is the way to go. I didn't yet understand what this sould buy me with a Radeon7500, but at least I have the impression that these patches don't do any harm to me when running my beloved FlightGear, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] R100 GL_ATI_texture_env_combine3
Ian, now that you've merged in the software support for combine3 from the Mesa trunk, I'm trying to get it working in hardware on R100 with texmem (impatient as I am ;) ). Where do I find at least a short explanation on the effect this patch should show to me (to the user) ? The only impression I have after a short test is decreased frame rate in FlightGear under certain conditions. I'm pretty shure this is not your primary intention with this patch ;-) So obviously this patch is considered to improve something else that FlightGear das not benefit from, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] R100 GL_ATI_texture_env_combine3
That would be easy enough to verify with oprofile. Just take a profile with and without the patch. In order to get profile data on the GL driver, do this: oprofpp -l /usr/X11R6/lib/modules/dri/radeon_dri.so Thanks for the explanation. If there's anything else I can do to support your effort instead of pointing to FlightGear related trouble every day I'd be glad to hear - I mean, except writing C code, you don't really want to look at my C skills Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Configuration file format survey
[...] The notion that users dont edit config files by hand may be all fine and good in the microsoft world but last time I checked I was using linux. You can't make the same assumptions about what users want to do as you can in the microsoft world. I'd like to add _strong_ support to this opinion, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Merge from trunk to texmem-0-0-1
[ Ian wrote ] There have been rumblings on [EMAIL PROTECTED] about problems with Radeon in 4.2.99.4, but I didn't think that those problems had propogated into DRI CVS yet. That's a shame. :( I think it's the other way round: The DRI stuff that got merged into XFree86 4.2.99.x 'releases' has _never_ever_ been usuable with FlightGear on Radeon7500, so it's not surprising that problems show up with XFree86 pre releases :-/ In purpose to find something usuable for FlightGear that features TL on my Radeon7500 I'm now testing every branch I can find in CVS ;-))) Maybe sometime we could offer a recommendation of what would be useful to get merged into XFree86 In the mean time, you ought to be able to revert back to texmem-0-0-1-20030123-trunk-premerge and update everything EXCEPT programs/Xserver/hw/xfree86/drivers/ati/. [...] Thanks, I'll try ASAP (I'll be out of office for a few days, I think I'll need a DRI capable Notebook ;-), Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] R200 notes issues
On Tue, Jan 07, 2003 at 03:40:09PM +0100, Martin Spott wrote: http://document.ihg.uni-duisburg.de/bitmap/Radeon/Solace-4.x.png [...] Wow, that's a really cool failure mode... What's your GL_draw_method (in ~/.Solace/registry) set to? Try changing it to 1 or 0... Yep, this circumvences the bug, Which one? 1 uses vertex arrays with glArrayElement, 0 uses immediate mode. (2 uses glDrawElements. [...] Setting GL_draw_method to 0 prevents from drawing these nice artifacts as shown in the picture. Please see my next posting in a few minutes when I managed to upload the 'Carbon Copies' of two Solace-sequences. I'll see what GL_draw_method 2 shows on my display, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] R200 - what can I do to help?
On Tue, Jan 07, 2003 at 03:48:51PM +0100, Martin Spott wrote: [...] It was like the image that was supposed to be clipped because it was hidden became visible briefly as the light went by. It just happens briefly and then it is quickly corrected. This is probably not an accurate description, but there it is. Okay... could you set the value of testRender/capt to some directory with lots of free space and press 'k'? It'll record PPM-format screenshots... then send the appropriate frame(s) to me, preferrably as PNG or JPG. :) Are you still interested in these ones ? Yeah. I put two sequences onto the web server. They are approx. 250 frames each. Be careful - even converted to PNG these archives are still 19 MByte each. The filenames should speak for themselves. I included a log of the terminal output of 'Solace'. BTW, the second one ends with a crash - 'Solace' writes something like Radeon timed out to the terminal: http://document.ihg.uni-duisburg.de/bitmap/Radeon/Solace-dlistMax0-draw_method1.tar http://document.ihg.uni-duisburg.de/bitmap/Radeon/Solace-dlistMax1024-draw_method1.tar This not only cures the artifacts I encountered, this also cures the flickering torus and - as far as I can tell now - it cures the X server crashes with my Radeon7500. Even with GL_draw_method set to 1, Then there's a problem with glArrayElement() in the R200 driver while recording a displaylist. I'm using the 'radeon' driver for my Radeon7500, not 'r200'. The specific piece of code that it's running is this (while a displaylist is being recorded in GL_COMPILE_AND_EXECUTE mode): [... some code ...] This is not for me - I'm not skilled enough to deal with details of the code, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] R200 notes issues
In article au0450$ak$[EMAIL PROTECTED] you wrote: Message-ID: [EMAIL PROTECTED] References: atlt6a$sqm$[EMAIL PROTECTED] [EMAIL PROTECTED] Mime-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: [EMAIL PROTECTED]; from [EMAIL PROTECTED] on Fri, Dec 20, 2002 at 12:47:34PM +0100 Sender: [EMAIL PROTECTED] Errors-To: [EMAIL PROTECTED] Precedence: bulk List-Help: mailto:[EMAIL PROTECTED]?subject=help List-Post: mailto:[EMAIL PROTECTED] List-Subscribe: https://lists.sourceforge.net/lists/listinfo/dri-devel, mailto:[EMAIL PROTECTED]?subject=subscribe List-Id: dri-devel.lists.sourceforge.net List-Unsubscribe: https://lists.sourceforge.net/lists/listinfo/dri-devel, mailto:[EMAIL PROTECTED]?subject=unsubscribe List-Archive: http://sourceforge.net/mailarchive/forum.php?forum=dri-devel Date: Fri, 20 Dec 2002 10:48:38 -0800 Content-Type: text/plain; charset=us-ascii On Fri, Dec 20, 2002 at 12:47:34PM +0100, Martin Spott wrote: There are sporadic rendering bugs in FlightGear, however. Every ~40 frames or so, I'll see a large triangle or two flash on the screen. Like these ones ? http://document.ihg.uni-duisburg.de/bitmap/Radeon/Mesa-4.0.4_3.png Did you know that 'Solace' - recently mentioned on this list - also shows this sort of artifacts ? And I can guarantee it's not a bug in Solace. ;) http://document.ihg.uni-duisburg.de/bitmap/Radeon/Solace-4.x.png Maybe this program is not that complex and could server as a test case for DRI/Mesa-4.x, Wow, that's a really cool failure mode... What's your GL_draw_method (in ~/.Solace/registry) set to? Try changing it to 1 or 0... also, I notice a problem with the outlines on the various objects which have them (the group of torii and the bubble-shaded thing on the right). The easy workaround (in Solace anyway) is to change GL_line_method to 0, which switches it to immediate mode (it still records a displaylist though). BTW, for an explanation of the various settings (so that people really could use Solace as a driver stress test), type d_set from the controlling terminal (and you can also use this command to change the settings on-the-fly). I must take issue with your claim that Solace is 'not that complex' though. ;) -- http://trikuare.cx --- This SF.NET email is sponsored by: The Best Geek Holiday Gifts! Time is running out! Thinkgeek.com has the coolest gifts for your favorite geek. Let your fingers do the typing. Visit Now. T H I N K G E E K . C O Mhttp://www.thinkgeek.com/sf/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] R200 notes issues
http://document.ihg.uni-duisburg.de/bitmap/Radeon/Mesa-4.0.4_3.png Did you know that 'Solace' - recently mentioned on this list - also shows this sort of artifacts ? And I can guarantee it's not a bug in Solace. ;) http://document.ihg.uni-duisburg.de/bitmap/Radeon/Solace-4.x.png Maybe this program is not that complex and could server as a test case for DRI/Mesa-4.x, Wow, that's a really cool failure mode... What's your GL_draw_method (in ~/.Solace/registry) set to? Try changing it to 1 or 0... Yep, this circumvences the bug, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] R200 - what can I do to help?
Yes, that would be the one. If you take all the torus together it reminds me of a cartoonish framework for what could be overall a sphere. Imagine stretching a piece of cloth around the whole grouping ... Also, what do you mean by flickers? It was like the image that was supposed to be clipped because it was hidden became visible briefly as the light went by. It just happens briefly and then it is quickly corrected. This is probably not an accurate description, but there it is. Okay... could you set the value of testRender/capt to some directory with lots of free space and press 'k'? It'll record PPM-format screenshots... then send the appropriate frame(s) to me, preferrably as PNG or JPG. :) Are you still interested in these ones ? Oops - mistype. Switching the GL_draw method to 0 correct all of the anomalies I was seeing in the display. That makes more sense. :) Sounds like it's a problem with displaylists and vertex arrays. Does it still happen if you set the value of GL_dlistMax to 0? This not only cures the artifacts I encountered, this also cures the flickering torus and - as far as I can tell now - it cures the X server crashes with my Radeon7500. Even with GL_draw_method set to 1, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] R200 - what can I do to help?
Oops - mistype. Switching the GL_draw method to 0 correct all of the anomalies I was seeing in the display. That makes more sense. :) Sounds like it's a problem with displaylists and vertex arrays. Does it still happen if you set the value of GL_dlistMax to 0? This not only cures the artifacts I encountered, this also cures the flickering torus and - as far as I can tell now - it cures the X server crashes with my Radeon7500. Even with GL_draw_method set to 1, O.k., the crash doesn't get prevented but it gets delayed heavily, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] R200 - what can I do to help?
Also, if whoever it was who posted that screenshot could change the Solace setting of GL_draw_method to 0 (which switches to immediate mode rendering rather than using vertex arrays) and see if that continues with the funkiness, that would be another useful data point. :) I should step in here because I think you are referring to my screenshot. I'm not at home these days and I will continue to answer your questions as soon as I'm back to the machine I was running 'Solace' on, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- 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] R200 notes issues
There are sporadic rendering bugs in FlightGear, however. Every ~40 frames or so, I'll see a large triangle or two flash on the screen. Like these ones ? http://document.ihg.uni-duisburg.de/bitmap/Radeon/Mesa-4.0.4_3.png Did you know that 'Solace' - recently mentioned on this list - also shows this sort of artifacts ? http://document.ihg.uni-duisburg.de/bitmap/Radeon/Solace-4.x.png Maybe this program is not that complex and could server as a test case for DRI/Mesa-4.x, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- This SF.NET email is sponsored by: The Best Geek Holiday Gifts! Time is running out! Thinkgeek.com has the coolest gifts for your favorite geek. Let your fingers do the typing. Visit Now. T H I N K G E E K . C O Mhttp://www.thinkgeek.com/sf/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mesa version and Radeon driver
On Mon, Dec 16, 2002 at 06:44:46PM +0100, Michel Dänzer wrote: DRI with Mesa-4.0.4 - as suggested for shipping with XFree86-4.3: http://document.ihg.uni-duisburg.de/bitmap/Radeon/Mesa-4.0.4.png Is the 4.0.4 screenshot from after I merged fixes from the trunk? I believe so. The screenshot dates on 2002-12-13 18:04 (CET) and the CVS update was taken very few hours before. I must admit that I was a bit lazy today so I didn't want to retype the whole message so I'd add something here. The most interesting thing (for _me_) is the evidence, that the picture does _not_ differ dependent on the X server I use. I can throw in different X server binaries, but the real difference becomes obvious when I change the underlying OpenGL libraries - wether they com from SuSE-8.1, from DRI/Mesa-4.0.4 or from DRI/Mesa/5.x This implies - as I understand the topic - that the Mesa libraries have far the most influence on what the user looks at. Well, it doesn't look that much better, does it? Do you really think it's worth rushing in Mesa 5 for that? To be honest, the branch with Mesa-4.0.4 is currently not worth talking about when it comes to using FlightGear. I built a _lot_ of DRI (Mesa-4.x) trees during the past months to have the impression that improvement is unlikely to happen here. So Mesa-5.x appears to be the big step that promises - for me - an XFree86 release that I would count on. Sure, the 'old' code has problems, but at least it's well tested with all drivers. You can always use DRI CVS or 4.2.0 if that suits you better. If the user had to consider XFree86-4.3 as 'broken' because of non functional OpenGL support, so why should people use it ? These are disproportionate strong words, but I believe the 'user' will think this way once he has the decision to make, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] No Radeon lockup with FlightGear in fullscreen
On Fri, Dec 06, 2002 at 04:29:14PM +0100, Michel Dänzer wrote: So apparently the problem stems from the interaction between 3D and 2D, e.g. missing synchronization, locking problems, indirect buffer issues, This is my impression. I did another run, I did a local login via xdm and killed everything (including the display manager) except one wterm, which I used to start FlightGear. I was at least able to fly several minutes before the screen got locked. Unfortunately I didn't have a debugger running, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- 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 just ran FlightGear with this branch (instead of employing binary snapshots) on my Radeon7500. Everything is quite fast, the colours look perfect, the previously known feature of everything appearing too dark has gone ! Hmmm, today I had to realize that this is still dependend on the direction you look at. But still better than before, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- 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
