Re: Radeon X1600?
On Thu, 16 Feb 2006, Michel [ISO-8859-1] D?nzer wrote: On Thu, 2006-02-16 at 10:02 +0100, Michel D??nzer wrote: On Thu, 2006-02-16 at 00:52 -0500, Vladimir Dergachev wrote: If X1600 is a completely new chip then it is likely we are not going to get any documentation within 1.5-2 years from the release. This has been so with all of ATI's new chips: mach64, rage128, radeon, Rage Theatre, Rage Theatre 200. The only exceptions were, I believe, 2d support for rage128 and radeon cards - and that turned out to be very similar to mach64. Actually, AFAIR all of Rage128, R100 and R200 had pretty decent support including rather shortly after release, [...] I meant to say 'including 3D'. 3d support was Rage128, R100 and R200 was done by Precision Insight and I distinctly remember working on TV-in of AIW Rage128 card while the card had no 3d drivers (I would have noticed as I looked at all the information sources that were publicly available to compliment ATI's documentation). This was, of course, after the release. R200 initial 3d support was done, AFAIK, by Kevin Martin, and involved using R100 code - thus it did not support TL. I am somewhat hazy on timing for Radeons. My estimate of 1.5-2 years delay before open source drivers appear is based on a simple consideration: 0 - product is released +1 year- ATI releases register specs to some developers under NDA +1.5 years - stable 2d driver with decent acceleration appears +2 years - 3d driver with at least triangles and textures appears. The development times increase if the chip can easily lockup when having unexpected values into registers (like what happens with 3d pipeline on Radeon 9800) I am not sure what the development timeline of ATI binary driver is but I assume it is at least 3 months for a new chip or they would not need more than one person. best Vladimir Dergachev -- Earthling Michel D??nzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer
Re: where is libdrm
On Mon, 10 Oct 2005, Ben Skeggs wrote: Am Montag, den 10.10.2005, 02:41 -0400 schrieb Vladimir Dergachev: Stupid question - what is the official place to get libdrm from ? I read through the webpages (both mesa3d and DRI) and searched on Google, but I dont' seem to find it. It's in drm cvs: http://cvs.freedesktop.org/dri/drm/ Thank you ! For some reason I was intent on finding a separate libdrm module.. best Vladimir Dergachev --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: new id of card
On Sun, 2 Oct 2005, Korotenko Vladimir Nikolaevitch wrote:
a'm add this string in drm_pciids.h to detect my video card
{0x1002,0x4152,0,ATI Radeon RV360},\
{0x1002,0x4172,0,ATI Radeon RV360 display},\
Hi Vladimir,
Does this mean that you tried R300 driver with your card ? Does it
work ?
Also, are both of these for a single card (i.e. is the second one for
the other head) ?
thank you !
Vladimir Dergachev
---
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
where is libdrm
Stupid question - what is the official place to get libdrm from ? I read through the webpages (both mesa3d and DRI) and searched on Google, but I dont' seem to find it. thank you ! Vladimir Dergachev --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: dual-TMU support
On Thu, 15 Sep 2005, Chris Chiappa wrote: Wasn't sure whether to send this to dri-users or dri-devel but it's sort of a bug report so I figured I'd send it here. Following the Building instructions on the DRI Wiki I believe I have DRI working on my Thinkpad T42 (Radeon Mobility M10). glxinfo tells me: direct rendering: Yes and I seem to get about 1340 fps in glxgears. Not great, but certainly better than software. Quake 2 seems to run fine with glx support. (Both glxgears and Q2 print various messages like TODO - double side stencil ! and user error: Need more than 2 vertices to draw primitive QS ! but I assume those are mostly debugging-related). My (perhaps overly ambitious) TODO messages mark code that needs work. For example, double side stencil does not work, so if you want to play with it all you have to do is grep for the text of message in the source code. The user error messages is due to the fact that glxgears sometimes outputs insufficient number of vertices to draw a primitive - for example only 2 vertices for a quad. goal, however, would be to be able to run World of Warcraft. It runs under Wine with fglrx, but I experience frequent crashes and of course in any case would prefer to use free drivers. :) Running WoW with the r300 driver yields this complaint: Your 3D accelerator card is not supported by World of Warcraft. Please install a 3D accelerator card with dual-TMU support. Silly question - what is TMU ? Anyone know if this is a known limitations or whatnot? For kicks, in case it's interesting to anyone, I put my Xorg.log up as http://www.chiappa.net/~chris/xorg-r300.log.gz Great, thank you ! Vladimir Dergachev -- ..ooOO [EMAIL PROTECTED] | My opinions are my own OOoo.. ..ooOO [EMAIL PROTECTED] | and certainly not those OOoo.. ..ooOO http://www.chiappa.net/~chris/ | of my employer OOoo.. --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42 plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42 plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: offtopic: quake3 source
On Thu, 15 Sep 2005, Bernardo Innocenti wrote: Jacek Popławski wrote: I don't know if you are interested, but there is quake3 source available for a while... You can download it from: http://icculus.org/quake3/ By the way, quake3 (original version) doesn't work any more with latest Mesa + DRM on both r200 and r300. It just hangs immediately after entering a map. Have you tried disabling some graphics options ? I just run Quake3 on somewhat old version of Mesa, but recent DRM and r300 driver. best Vladimir Dergachev Last time I've checked, the 64bit version of quake3 (icculus version) displays garbage instead of textures. Not sure wether it's a Mesa or Quake bug. -- // Bernardo Innocenti - Develer S.r.l., RD dept. \X/ http://www.develer.com/ --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42 plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Problem with agp and r300 driver in powerpc
PS: Is there any debugging output or program which r300 project may find useful? PSS: Now I'm sure that my card works, so volodya can commit the patch to cvs. Done. Thank you ! Vladimir Dergachev --- 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: Kernel / user interface for new memory manager
On Wed, 24 Aug 2005, Stephane Marchesin wrote: Alan Cox wrote: The log design presents numerous opportunities for rogue processes to do bad things. At some level, that's inherent in the nature of direct rendering. If you don't trust the processes, don't enable direct rendering. Thats a very poor answer to the problem. DRI needs to be moving towards being more secure, and building in assumptions of insecurity just makes it worse when better cards are used. Security is more than just the memory manager. To enforce video memory protection, we'd have to audit the code and add memory protection to existing drm modules. That is quite a lot of work, and requires extensive knowledge of each card. So I don't think it's worth the trouble with current cards. Something like that has already been added to R300 driver and should not be portable to radeon and r200. best Vladimir Dergachev --- 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 + FreeBSD -CURRENT?
I would expect a difference, but, it might have changed.. FYI, FreeBSD -CURRENT does not use fixed major number any more. It's dynamically assigned when it's created. Cool ! Is this more devfs style (with kernel space code) or udevd style (with userspace code) ? best Vladimir Dergachev --- 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_dri compiling
On Sun, 21 Aug 2005, john wrote: hi! i'm not too experienced in programming, but here it goes: but i've been able to check out the Mesa cvs and the r300 cvs. i've been trying for quite a long time, to compile r300 Mesa drivers. the drm works fine from r300 cvs, but i cant get mesa to compile. if i try to compile the r300 code from Mesa cvs the compile finishes cleanly, but I get no direct 3D acceleration. libGL warning: 3D driver returned no fbconfigs. libGL error: InitDriver failed libGL error: reverting to (slow) indirect rendering display: :0 screen: 0 direct rendering: No Take a look in /var/log/Xorg.0.log - I bet it says direct rendering disabled. You need to use DRM from DRI CVS - it has proper version number that Xorg Xserver recognizes. The reason for the check is that previous DRM versions provided 2d acceleration only and using Mesa driver with them will not work. if I lndir the r300 code from r300 cvs, the build doesn't finish: output in attached file. No, it is not supposed to - there had been significant changes in Mesa. best Vladimir Dergachev i think it's just me, but i would like to be shure i can't help you guys! THANX for the hard work (i got it to compile about one month ago, once, but am still using that driver!) --- 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 [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R430 (Radeon X800 XL AGP)
Now the bad stuff: - Some programs run without acceleration. LIBGL_DEBUG=verbose reports things like: libGL error: dlopen .../r300_dri.so failed (.../r300_dri.so: undefined symbol: _glapi_add_dispatch) Did you install Mesa from CVS ? There were quite a few big change in CVS and one now needs to install the library as well, not just the drivers. best Vladimir Dergachev strace shows it opening the right versions of libGL and r300_dri, and libGL does have that symbol, and of course glxinfo and glxgears do run with direct rendering. So this is a mystery. - Software GL consistently segfaults the X server whenever certain operations (such as a window resize) are attempted. For example one of my test programs that does _not_ run with direct rendering does a glutReshapeWindow on startup and it segfaults X.org every time. The good news is that the server seems to restart easily and e.g. the machine has not completely locked up on me yet. - The Building page on the wiki seems to be out of date. Mesa now requires libdrm to be installed and registered with pkg-config. -Dave Dodge --- 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 [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel --- 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 [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r300 + FreeBSD -CURRENT?
And so on, through /dev/dri/card254 Mind you, /dev/dri/card0 exists: [ [EMAIL PROTECTED] - ~ ]: ls -la /dev/dri total 1 dr-xr-xr-x 2 root wheel 512 Aug 21 18:37 . dr-xr-xr-x 5 root wheel 512 Dec 31 1969 .. crw-rw-rw- 1 root wheel0, 162 Aug 21 18:35 card0 Any ideas? Is the major ok ? On my (linux) system I get: crw-rw-rw- 1 root root 226, 0 Aug 21 19:07 card0 I would expect a difference, but, it might have changed.. Also, check that the DRM driver knows your PCI id. best Vladimir Dergachev Adam --- 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 [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel --- 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 [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] patches wanted !
On Sat, 20 Aug 2005, Dave Airlie wrote: What I meant is to get 2d working using DRI driver (i.e. submitting commands using CP engine, rather than MMIO registers as happens without DRM driver loaded). In for a penny in for a pound, (old saying..) i.e. if I could do that I would have working 3D... the CP crashes on startup... I assume that you have a version of PCIGART working, right ? You can test this using MMIO by doing bitblt from GART memory to video memory, for example. just don't add PCIE pciids to the drm until I or someone else gets it working... Can we add them in a commented out way ? best Vladimir Dergachev Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie Linux kernel - DRI, VAX / pam_smb / ILUG --- 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
[R300] patches wanted !
Hi all, As you probably know the code from r300.sf.net got merged into main Mesa and DRM trees. This is great, but it looks like everyone thinks they should check in only the perfect patches. This won't work as few people (if any) can spend days focused on the same issue. Me being a prime example - I can spend half hour in the evening on a problem I know how to solve, but I was not able to do anything more thorough for at least a few months. So, it is ok to post the following patches: * do you know a place in the driver that is broken, but you don't know how to fix offhand ? Please, submit a WARN_ONCE patch that has a WARN_ONCE() statement and a comment explain what is broken * do you know an application that does not work properly and which feature is broken ? Please, let us know. * Can you get PCI-Express cards to do a tiny bit more (like get 2d working) than they do now - patch is fine. * Feel shaky about a patch ? Make it easy to remove it afterwards and switch it on/off during compile time. * Think there is a better implementation of a function ? Make another version so people can switch from one to another and report results. Well, you get the idea - there is still much fun to be had with this driver :) best Vladimir Dergachev --- 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] patches wanted !
On Fri, 19 Aug 2005, Jaakko Niemi wrote: On Fri, 19 Aug 2005, Vladimir Dergachev wrote: * Can you get PCI-Express cards to do a tiny bit more (like get 2d working) than they do now - patch is fine. I'm writing this from a screen run on a Radeon X700 Pro, on pci-e bus, with the xorg packages from Debian unstable. Are there pci-e cards that do not even work in 2d? Does the log file say DRI enabled ? What I meant is to get 2d working using DRI driver (i.e. submitting commands using CP engine, rather than MMIO registers as happens without DRM driver loaded). As for 3d, just let me know what register dumps are needed... Unfortunately I don't have time to dig into the driver. Someone else would have to answer this - there are a ton of registers and I don't know which ones are important for PCIe. thank you ! Vladimir Dergachev --j --- 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: xpress 200m
On Fri, 19 Aug 2005, Vitja Makarov wrote: I have compiled Xorg version 6.8.99.900 (6.9.0 RC 0), I was unable to get it working in 2d. xserver start but standard x11 background is corrupted with horizontal and vertical black lines, X-cursor is ok. After few seconds system hangs with no kernel panic according to leds, no respond on ctrl-alt-1, sysrq and so on ( so I can say xorg server's ati driver doesn't work with my card( Try starting ATI Xserver driver, then quitting X and starting Xorg RC 0. If this works, this is probably only a matter of initializing a few registers. best Vladimir Dergachev x server log file attached. --- 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: xpress 200m
On Wed, 17 Aug 2005, Vitja Makarov wrote: Hi all! Is it possible to add 200m support to r300 drivers? If so I'm going to do this stuff. This is lspci output related to the card [snip] according to Xorg.log: (--) fglrx(0): Chipset: RADEON XPRESS 200M (RS480 5955) (Chipset = 0x5955) So as I understand my card is based on rs480 5955 chip that isn't r300 ( Any ideas? Hi Vitja, chances are that r300 driver might work with this chipset. The first thing to find out is whether Xorg from CVS works with your card. If it does, get DRM from CVS, add your PCI id, install the module and try to get Xserver to say DRI enabled in the log. If 2d still works, you can try compiling r300 mesa driver - chances are it will work as well (you'll need to add your pci id to it too and tell it that you have RV350). best Vladimir Dergachev vitja. --- 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: Radeon RV350 (9550), xorg cvs 29.07.2005
Here is dmesg output: [drm] Initialized drm 1.0.0 20040925 PCI: Unable to reserve mem region #1:[EMAIL PROTECTED] for device :01:00.0 [drm] Initialized radeon 1.17.0 20050720 on minor 0: ATI Technologies Inc RV350 AS [Radeon 9600 AS] [drm] Used old pci detect: framebuffer loaded mtrr: 0xb000,0x1000 overlaps existing 0xb000,0x800 X: Corrupted page table at address 2aaab51b3000 PGD 37996067 PUD 37977067 PMD 3653f067 PTE c25fd037 Bad pagetable: 000f [1] PREEMPT I hope someone more knowledgable about amd64 will chime in - are we supposed to see those Corrupted page table at address 2aaab51b3000 messages ? What can cause this ? (I've never seen kernel driver causing anything like this, let alone a userspace program). Also, there was a similar report before: http://www.opensubscriber.com/message/dri-devel%40lists.sourceforge.net/1865882.html Additionally, google found this: http://softwareforums.intel.com/ids/board/print?board.id=14message.id=1099 (careful - this is a print form, so it will try to print when you are viewing the page) It shows up a very similar error but with Intel VTune analyzer, while using Linux 2.6.12. So it is possible that the problem is not with X or DRM but rather with the kernel itself. Michal, could you test 2.6.11 ? thank you ! Vladimir Dergachev --- 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: Radeon RV350 (9550), xorg cvs 29.07.2005
On Tue, 9 Aug 2005, [iso-8859-2] Micha³ Pytasz wrote: Hi, On Tuesday 09 of August 2005 18:04, Vladimir Dergachev wrote: Version of my kernel is gentoo-2.6.12-r7, which is based on 2.6.12.3 (exact list of applied patches is here: http://dev.gentoo.org/~dsd/genpatches/trunk/2.6.12/ ) I am attaching my kernel configuration. I could build vanilla kernel if it would help debug problem. Well, I ran out of ideas. If it is not too much trouble try a vanilla kernel, on the off chance that something is different there. Just tested it with vanilla kernel 2.6.13-rc6 - results are the same. What about 2.6.12-4 - there were some amd64 specific changes, though I am not certain whether they would apply here. For comparison here is the relevant part from my Xserver log: (II) RADEON(0): [drm] added 8192 byte SAREA at 0xf99de000 (II) RADEON(0): [drm] mapped SAREA 0xf99de000 to 0xaf87a000 (II) RADEON(0): [drm] framebuffer handle = 0xd000 (II) RADEON(0): [drm] added 1 reserved context for kernel (II) RADEON(0): [agp] Mode 0x1f000201 [AGP 0x8086/0x3340; Card 0x1002/0x4e50] (II) RADEON(0): [agp] 8192 kB allocated with handle 0x0001 As you can see SAREA address is high too (this is on Pentium M, 32 bits) and the very next messages says that it was mapped at some virtual address in Xserver space. The code that does this is located in xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_dri.c If you feel like it poke around, insert some xf86DrvMsg(X_INFO, 0, hello) to see what happens. In particular it would be useful for another pair of eyes to check for the following: * any confusion between int, long and similar unsigned types * above, especialy as applied to addresses and sizes * does mmap work ok on your system ? Maybe some issues with flags passed to it ? thank you ! Vladimir Dergachev Michal
Re: Radeon RV350 (9550), xorg cvs 29.07.2005
Hi Michal, (II) RADEON(0): [drm] DRM interface version 1.2 (II) RADEON(0): [drm] created radeon driver at busid pci::01:00.0 (II) RADEON(0): [drm] added 8192 byte SAREA at 0xc2bfc000 Program terminated with signal SIGKILL, Killed. The program no longer exists. (gdb) bt No stack. This is very interesting - the program is killed rather than receive sig11 right after allocating SAREA. Which Linux kernel are you running ? Do you have anything like SELINUX or or out-of-memory handler enabled ? Anyone else has seen something like this before ? thank you ! Vladimir Dergachev --- 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: Radeon RV350 (9550), xorg cvs 29.07.2005
On Mon, 8 Aug 2005, [iso-8859-2] Micha? Pytasz wrote: * get DRM from DRI CVS (i.e. freedesktop CVS) and check that the module loads fine, e-mail us any kernel messages it produces (should be at least a few) [drm] Initialized drm 1.0.0 20040925 PCI: Unable to reserve mem region #1:[EMAIL PROTECTED] for device :01:00.0 [drm] Initialized radeon 1.17.0 20050720 on minor 0: ATI Technologies Inc RV350 AS [Radeon 9600 AS] [drm] Initialized radeon 1.17.0 20050720 on minor 1: ATI Technologies Inc RV350 ?? [Radeon 9550] (Secondary) [drm] Used old pci detect: framebuffer loaded Do you have two cards in this computer ? If so could you try removing one and see whether the other continues to work. is still alive. Let us know whether you can see xterm and whether it is usable. Well, still blank screen. xorg.log attached. (I could and I can ssh to the machine) Whoops, in the command line I sent you it should X -verbose - this way all the log messages make it to the log. Could you try starting X in gdb (remotely) waiting till it turns black and then pressing ^C and bt[ENTER] to get a backtrace ? It would be curious to see where it is stuck. Press cont[ENTER] to let it continue so you can kill it in case it can still terminate gracefully. Also, please post your results to dri-devel@ - this way they are archived so search engines can find them for other people. dri-devel@lists.sourceforge.net I guess? Yep. thank you ! Vladimir Dergachev
Re: Radeon RV350 (9550), xorg cvs 29.07.2005
module loads fine, e-mail us any kernel messages it produces (should be at least a few) [drm] Initialized drm 1.0.0 20040925 PCI: Unable to reserve mem region #1:[EMAIL PROTECTED] for device :01:00.0 [drm] Initialized radeon 1.17.0 20050720 on minor 0: ATI Technologies Inc RV350 AS [Radeon 9600 AS] [drm] Initialized radeon 1.17.0 20050720 on minor 1: ATI Technologies Inc RV350 ?? [Radeon 9550] (Secondary) [drm] Used old pci detect: framebuffer loaded Hi Michal, I am a bit confused by these messages - did you add PCI id for your card to pciids.txt table ? If so, you should not add the id for the secondary - it is a fake used by Windows (cause Windows thinks one pci device - one monitor, go figure). The primary id for your card is already in the table, so this should work fine. best Vladimir Dergachev --- 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: radeon_driver.c SetFBLocation and r300 cards
On Sun, 7 Aug 2005, Dave Airlie wrote: In this function there is a section in an if (IS_R300_VARIANT) which returns, and later in the function there is another section setting display priorities for IS_R300_VARIANT something is wrong there... You are quite right, we should get rid of the code that forces fbLocation to 0. Aside from not setting INIT_MISC_LAT_TIMER, it causes problems with video capture on All-in-Wonder style cards. best Vladimir Dergachev Dave. --- 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 --- 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: radeon_driver.c SetFBLocation and r300 cards
On Sun, 7 Aug 2005, Vladimir Dergachev wrote: On Sun, 7 Aug 2005, Dave Airlie wrote: In this function there is a section in an if (IS_R300_VARIANT) which returns, and later in the function there is another section setting display priorities for IS_R300_VARIANT something is wrong there... You are quite right, we should get rid of the code that forces fbLocation to 0. Aside from not setting INIT_MISC_LAT_TIMER, it causes problems with video capture on All-in-Wonder style cards. I removed the offending lines - could people with R300 test recent X.org CVS code ? In particular, it might improve stability on Radeon 9800 cards. best Vladimir Dergachev --- 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: [Linux-fbdev-devel] CRTC scanout buffer types
I agree that something like the above is acceptable, exept that we need an extra field for offset and another if indexed color or not. So something like: A:2/0/R:10/2/G:10/12/B:10/22//I This is getting more cryptic by the minute. Can't we have a simple field: value lines ? Something like: AlphaBits: 2 AlphaOffset: 0 best Vladimir Dergachev --- 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: [Linux-fbdev-devel] CRTC scanout buffer types
On Mon, 8 Aug 2005, Antonino A. Daplas wrote: Vladimir Dergachev wrote: I agree that something like the above is acceptable, exept that we need an extra field for offset and another if indexed color or not. So something like: A:2/0/R:10/2/G:10/12/B:10/22//I This is getting more cryptic by the minute. Can't we have a simple field: value lines ? Something like: AlphaBits: 2 AlphaOffset: 0 The problem with doing that is you need to set everything in one go. Separating all those fields into different sysfs attributes will have a problem with synchronization. One workaround is to have another attribute 'Activate'. Nothing is set until the 'Activate' attribute is written to. There is still the problem of another process changing the other attributes behind the back of the original process. I think Activate is a good idea and it kinda mimics what graphics chips themselves do, so another reason to like it. As for simultaneous access - does it actually make sense that two programs would want to change screen format at the same time ? Even if access is serialized in some fashion, at most one of the programs will get format that it requested, so we lose nothing by allowing it to be none. best Vladimir Dergachev Tony --- 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 driver
On Fri, 5 Aug 2005, F. Heitkamp wrote: On Thu, 4 Aug 2005, Vladimir Dergachev wrote: On Thu, 4 Aug 2005, F. Heitkamp wrote: Are you using recent Mesa CVS ? If yes, there are some bugs there due to recent code changes.. Yes. I was wondering though, should I use the Mesa from Xorg CVS or the CVS Mesa when experimenting with the r300 driver? CVS Mesa - there have been quite a few changes, so I doubt the driver will even compile with older code. best Vladimir Dergachev --- 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 DRI killing X
On Fri, 5 Aug 2005 [EMAIL PROTECTED] wrote: Small update that might help... taking the setup that works, unloading the drm and radeon modules, loading the newer drm and radeon modules (the versions reported by the radeon are 1.15.0 and 1.16.0, respectively), then restarting X causes the same error message about a corrupted page table. My guess therefore is that the problem I'm seeing is from some change in the DRM code, and not the Mesa drivers or Xorg. Brian - I forgot - I always get a message about bad page access from X on amd64. The reason is that such messages can also be due to unaligned access and are automatically fixed up by the kernel. So apparently X is doing something not fully by the book during startup (possibly having to do with video BIOS ?). best Vladimir Dergachev - Brian --- [EMAIL PROTECTED] wrote: I've been following the r300 driver development though I've not done much with it lately, but while trying the latest version that was merged into the DRI CVS tree I'm unable to successfully start X. First, the system: it's an Athlon 64 laptop with a 128MB Mobilitiy Radeon 9700 and 2 GB of RAM, running a custom 64-bit Linux with glibc 2.3.5, gcc 3.4.4, and a 2.6.12 kernel with the CKO patchset applied. The last version of the r300 driver before the merge to the drm and Mesa CVS repos works (mostly) fine, though I've not done a lot of testing with it. Now on to the crashing... I've gone back to what appears to be when it was first merged in (doing a cvs up -D 2005-07-21 for Mesa, drm, and xc (Xorg CVS repo)) and get the same error every time if I have the glx module enabled in the xorg.conf. In the terminal (I am sshing into the box since the screen goes black right before it dies and the console doesn't come back) I see: X Window System Version 6.8.99.900 (6.9.0 RC 0) Release Date: 01 August 2005 + cvs X Protocol Version 11, Revision 0, Release 6.8.99.900 Build Operating System: Linux 2.6.12-cko3 x86_64 [ELF] Current Operating System: Linux paradys 2.6.12-cko3 #3 Mon Aug 1 17:37:51 EDT 2005 x86_64 Build Date: 03 August 2005 Before reporting problems, check http://wiki.X.Org to make sure that you have the latest version. Module Loader present Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: /var/log/Xorg.0.log, Time: Wed Aug 3 19:37:08 2005 (==) Using config file: /etc/X11/xorg.conf (WW) INVALID MEM ALLOCATION b: 0xd800 e: 0xe000 correcting (WW) INVALID IO ALLOCATION b: 0x2000 e: 0x2100 correcting Killed And in dmesg I get: [drm] Initialized drm 1.0.0 20040925 ACPI: PCI Interrupt :01:00.0[A] - GSI 18 (level, low) - IRQ 209 [drm] Initialized radeon 1.16.0 20050311 on minor 0: ATI Technologies Inc RV350 [Mobility Radeon 9600 M10] X: Corrupted page table at address 2aaab5648000 PGD 7d61e067 PUD 7d594067 PMD 7d1e0067 PTE c22f9037 Bad pagetable: 000f [1] CPU 0 Modules linked in: radeon drm snd_via82xx snd_ac97_codec snd_mpu401_uart i2c_viapro i2c_core uhci_hcd yenta_socket rsrc_nonstatic pcmcia_core r8169 amd64_agp agpgart nls_iso8859_1 nls_cp437 vfat fat nls_base rt2500 snd_usb_audio snd_pcm snd_timer snd_page_alloc snd_usb_lib snd_rawmidi snd_hwdep snd joydev evdev Pid: 2075, comm: X Tainted: G M 2.6.12-cko3 RIP: 0033:[2b100470] [2b100470] RSP: 002b:7fb12cb8 EFLAGS: 00013283 RAX: 0080 RBX: 0007 RCX: 2aaab5648000 RDX: 2000 RSI: RDI: 2aaab5648000 RBP: 007696b0 R08: R09: c22f9000 R10: 00400200 R11: 004605f0 R12: 0002 R13: R14: 00769040 R15: 0002 FS: 2b2e7ef0() GS:80449340() knlGS: CS: 0010 DS: ES: CR0: 8005003b CR2: 2aaab5648000 CR3: 7dabc000 CR4: 06e0 Process X (pid: 2075, threadinfo 81007d7c4000, task 81007e0fd7b0) RIP [2b100470] RSP 7fb12cb8 and the last few lines of the Xorg log file (which I've attached as Xorg-crashed.0.log) are: drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 7, (OK) drmOpenByBusid: Searching for BusID pci::01:00.0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 7, (OK) drmOpenByBusid: drmOpenMinor returns 7 drmOpenByBusid: drmGetBusid reports pci::01:00.0 (II) RADEON(0): [drm] DRM interface version 1.2 (II) RADEON(0): [drm] created radeon driver at busid pci::01:00.0 (II) RADEON(0): [drm] added 8192 byte SAREA at 0xc22f9000 Now, as I said, it works fine with the last version of the r300 driver from before the merge (using Mesa, xc, and r300_driver trees last updated I think on 2005-07-15). At the terminal when I
Fixing R300
One change is that the remap table is now initialized to be full of -1 values. In addtion, all of the *_by_offset marcos misbehave in an obvious way if the specified offset is -1. SET_by_offset will do nothing, GET_by_offset will return NULL, and CALL_by_offset, since it uses GET_by_offset, will segfault. This works as I get the following backtrace with recent Mesa checkout: #0 0x in ?? () #1 0xb7ae1967 in execute_list (ctx=0x806b290, list=145) at main/dlist.c:6420 #2 0xb7ae2122 in _mesa_CallList (list=1) at main/dlist.c:6749 #3 0xb7b2ad87 in neutral_CallList (i=1) at vtxfmt_tmp.h:304 #4 0x0804b387 in draw () #5 0x0804bc1f in event_loop () #6 0x0804c09e in main () So apparently something gets called that does not exist. Would anyone have hints or suggestions on how I should start chasing this ? thank you ! Vladimir Dergachev --- 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: Fixing R300
I'm guessing that card_extensions in r300_context.c is wrong. There are a few extensions listed there that have NULL for their functions field. For example, the entry for GL_ARB_vertex_program should clearly be GL_ARB_vertex_program_functions instead of NULL. If there's an _functions structure in src/mesa/drivers/dri/common/extension_helper.h, it needs to be referenced in the dri_extension structure array. Yep, this was exactly the problem - thank you ! Fix is now in CVS. thank you Vladimir Dergachev --- 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 memory leak
Also, the code path pointed by Valgrind does not appear to cause this, at least not in the obvious way - putting printf(Hello\n) in r300NewProgram does not print many Hello's so this is not the actual culprit.. Does anyone have suggestions ? 'key' is never freed when existing key is found at _mesa_UpdateTexEnvProgram / _tnl_UpdateFixedFunctionProgram. Sorry, forgot to report this one... Fixed - thank you very much ! Vladimir Dergachev -- Aapo Tahkola --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel --- 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: Fixing R300
One change is that the remap table is now initialized to be full of -1 values. In addtion, all of the *_by_offset marcos misbehave in an obvious way if the specified offset is -1. SET_by_offset will do nothing, GET_by_offset will return NULL, and CALL_by_offset, since it uses GET_by_offset, will segfault. After some thinking - is it possible to reassign glNewList someplace else ? It would be nice to just have a default function that prints an error message and aborts at offset 0 (or offset -1) so the check for negative offset can be skipped. best Vladimir Dergachev --- 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 driver
On Thu, 4 Aug 2005, F. Heitkamp wrote: I have been trying to get the r300 driver to work. I have a dual athlon 2800MP and a Radeon 9550 card. I can get X Window to come up, but when I start mozilla and use the scroll widgets on web pages X locks up hard (i.e. takes 99% cpu.) I can post the messages from the server. The message is basically the framebuffer has become corrupt. Are you using recent Mesa CVS ? If yes, there are some bugs there due to recent code changes.. best Vladimir Dergachev I have not been able to get OpenGL (i.e 3D) working at all. I am using kernel 2.6.12.2 and the r300 driver from a couple weeks ago. Fred --- 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 --- 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: display lists broken in Mesa maybe due to glapi dispatch changes (?), and an Xthreads problem
Hi Ian, Your patch does fix build problems and the bug I have previously seen, however there is a new issue where glxgears segfaults in different place: #0 0x in ?? () #1 0xb7ba4947 in execute_list (ctx=0x806b290, list=145) at main/dlist.c:6420 #2 0xb7ba5102 in _mesa_CallList (list=1) at main/dlist.c:6749 #3 0xb7bedd67 in neutral_CallList (i=1) at vtxfmt_tmp.h:304 #4 0x0804b387 in draw () #5 0x0804bc1f in event_loop () #6 0x0804c09e in main () thank you ! Vladimir Dergachev On Wed, 3 Aug 2005, Ian Romanick wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ian Romanick wrote: In addition to my recent commit to Mesa CVS, try this patch. I have verified that everything builds and that glxgears works on a system with current X.org CVS installed. This patch *should* fix everything. :) I built it on a system *without* X.org 7.0rc0 on it, so there may still be build problems on those systems. Dunno. I have also attached the script that I used to test on r200. Run the script as ./mesa_test.sh ~/devel/Mesa-build/lib ~/devel/Mesa-build. The first parameter tells it where to find the DRI drivers (it uses it to set DRI_DRIVERS_PATH) and the second parameter tells it where to find Mesa's progs/demos progs/tests. It assumes that everything is already made in those locations. The only problem I hit was the following assertion in the ARB_vertex_program tests. I don't think that one is my fault, but it could be. r200_swtcl.c:103: r200SetVertexFormat: Assertion `VB-AttribPtr[VERT_ATTRIB_POS] != ((void *)0)' failed. I will try to test on r100, mga, and r128 tonight. I may be able to hit savage as well. If somebody can try i915, unichrome, and tdfx, that would rock. I'm really, really confused as to why this bug doesn't hit X.org CVS builds. The only way that it would not hit is if IN_DRI_DRIVER isn't set. If that's the case, it's also a bug. I'm not sure if we should just apply this patch (should just need the changes to dispatch.h) to X.org CVS or re-import Mesa with the patch applied. Fortunately for me, it's not my call to make. :) I'm going to try and figure out what's going on with the X.org build tomorrow (Thursday). My guess is that IN_DRI_DRIVER isn't included in the defines. As for the s/XTHREADS/USE_XTHREADS/ change, I'm not terribly happy about it. The problem is that XlibConf.h contains '#define XTHREADS' to make it easier to build X extensions in the modular build. This used to be set on the command line by imake. My *personal* opinion is that it should be set on the command line by configure. I went ahead and committed this part. 381936c4ef432d131188fe65617ec72b Mesa-200508031610.patch.gz 6242a7bddebf1e823f09802a71db0561 mesa_test.sh -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFC8VIoX1gOwKyEAw8RAjvoAJ9ZR5Ok0YV6WOjB9pWNiBUHFcQC+gCfeGMh h50ylD5bloXmpnNF5h2kMAE= =bYu+ -END PGP SIGNATURE- --- 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
Mesa (R300 ?) segfault
Hi all, I am getting the following segfault with recent checkout of Mesa (as of few seconds ago) and R300 driver: --- Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1211504128 (LWP 16041)] 0xb7b9fe78 in attrib_1_4 (v=0x1300) at tnl/t_vtx_generic.c:100 100 ATTRS( 1 ) (gdb) bt #0 0xb7b9fe78 in attrib_1_4 (v=0x1300) at tnl/t_vtx_generic.c:100 #1 0xb7b9e63f in choose_1_4 (v=0x1300) at tnl/t_vtx_api.c:464 #2 0xb7ba124a in _tnl_VertexAttrib4fvARB (index=136238856, v=0x1300) at tnl/t_vtx_generic.c:479 #3 0xb7b7a6ea in neutral_VertexAttrib4fvARB (index=1, v=0x1300) at vtxfmt_tmp.h:458 #4 0x0804b59b in init () #5 0x0804c07e in main () --- This appears to be internal to the Mesa and I have run out of obvious things to check. For some reason the variables v and index get their values screwed up repeatedly and, furthermore, attrib_1_4 gets too far with unmodified index (still at too high value). Any suggestions ? This is with gcc 3.3.6 thank you ! Vladimir Dergachev --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Mesa (R300 ?) segfault
things to check. For some reason the variables v and index get their values screwed up repeatedly and, furthermore, attrib_1_4 gets too far with unmodified index (still at too high value). Any suggestions ? The real answer is that it's not even supposed to be there. If you notice, (1, 0x1300) look like reasonable parameters to glNewLIst. Try Makes sense, thank you ! Unfortunately, I get build errors with your patch, like: main/api_arrayelt.c: In function `VertexAttrib1NbvNV': main/api_arrayelt.c:176: error: void value not ignored as it ought to be main/api_arrayelt.c:176: error: syntax error before ';' token main/api_arrayelt.c: In function `VertexAttrib2NbvNV': main/api_arrayelt.c:186: error: void value not ignored as it ought to be main/api_arrayelt.c:186: error: syntax error before ';' token main/api_arrayelt.c: In function `VertexAttrib3NbvNV': main/api_arrayelt.c:196: error: void value not ignored as it ought to be main/api_arrayelt.c:196: error: syntax error before ';' token main/api_arrayelt.c: In function `VertexAttrib4NbvNV': main/api_arrayelt.c:208: error: void value not ignored as it ought to be [.. continues.. ] best Vladimir Dergachev the patch that I posted to the thread display lists broken in Mesa maybe due to glapi dispatch changes (?), and an Xthreads problem. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFC7orkX1gOwKyEAw8RArFIAJ4pu76EwRalZXwvjBoMF1dwmX0OKwCcCpz7 tboU1qBmLRVxznS2abXF3tg= =Mo9Q -END PGP SIGNATURE- --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
R300 memory leak
Hi all, I've been running with code checked in Mesa tree and there appears to be rather large memory leak which can be plainly seen by running glxgears and watching top. Valgrind says it is caused by: ==11962== 1256224 bytes in 4742 blocks are definitely lost in loss record 54 of 55 ==11962==at 0x1B904C19: calloc (vg_replace_malloc.c:175) ==11962==by 0x1BD705C5: _mesa_calloc (imports.c:98) ==11962==by 0x1BD4712B: r300NewProgram (r300_shader.c:47) ==11962==by 0x1BD7F283: update_program (state.c:945) ==11962==by 0x1BD7F2C5: _mesa_update_state (state.c:976) ==11962==by 0x1BD32F91: radeonMakeCurrent (radeon_context.c:294) ==11962==by 0x1BD2EF24: DoBindContext (dri_util.c:515) ==11962==by 0x1BD2EF85: driBindContext3 (dri_util.c:548) ==11962==by 0x1B954821: BindContextWrapper (in /usr/X11R6/lib/libGL.so.1.2) ==11962==by 0x1B954B70: MakeContextCurrent (in /usr/X11R6/lib/libGL.so.1.2) ==11962==by 0x1B954D57: glXMakeCurrent (in /usr/X11R6/lib/libGL.so.1.2) ==11962==by 0x804B7EF: make_window (in /usr/X11R6/bin/glxgears) So apparently we never free programs.. Also, there is a small leak in DRI Hash code: ==11962== 28 bytes in 1 blocks are definitely lost in loss record 21 of 55 ==11962==at 0x1B9042E8: malloc (vg_replace_malloc.c:130) ==11962==by 0x1B96045B: drmMalloc (in /usr/X11R6/lib/libGL.so.1.2) ==11962==by 0x1B962D20: drmRandomCreate (in /usr/X11R6/lib/libGL.so.1.2) ==11962==by 0x1B96297B: HashHash (in /usr/X11R6/lib/libGL.so.1.2) ==11962==by 0x1B962AA4: HashFind (in /usr/X11R6/lib/libGL.so.1.2) ==11962==by 0x1B962B2C: drmHashLookup (in /usr/X11R6/lib/libGL.so.1.2) ==11962==by 0x1BD2EC4A: __driFindDrawable (dri_util.c:238) ==11962==by 0x1BD2EDD3: DoBindContext (dri_util.c:448) ==11962==by 0x1BD2EF85: driBindContext3 (dri_util.c:548) ==11962==by 0x1B954821: BindContextWrapper (in /usr/X11R6/lib/libGL.so.1.2) ==11962==by 0x1B954B70: MakeContextCurrent (in /usr/X11R6/lib/libGL.so.1.2) ==11962==by 0x1B954D57: glXMakeCurrent (in /usr/X11R6/lib/libGL.so.1.2) best Vladimir Dergachev --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
CVS access
I submitted a bug requesting CVS access a while ago, but it has not changed since - could someone knowledgable take a look and let me know what I did wrong ? thank you ! Vladimir Dergachev PS The URL is https://bugs.freedesktop.org/show_bug.cgi?id=3831 --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R300 memory leak
On Sat, 30 Jul 2005, Vladimir Dergachev wrote: Hi all, I've been running with code checked in Mesa tree and there appears to be rather large memory leak which can be plainly seen by running glxgears and watching top. One more piece of information - the memory leak increases with the size of the window. This is very surprising as I did not think window size should matter. Also, the code path pointed by Valgrind does not appear to cause this, at least not in the obvious way - putting printf(Hello\n) in r300NewProgram does not print many Hello's so this is not the actual culprit.. Does anyone have suggestions ? best Vladimir Dergachev Valgrind says it is caused by: ==11962== 1256224 bytes in 4742 blocks are definitely lost in loss record 54 of 55 ==11962==at 0x1B904C19: calloc (vg_replace_malloc.c:175) ==11962==by 0x1BD705C5: _mesa_calloc (imports.c:98) ==11962==by 0x1BD4712B: r300NewProgram (r300_shader.c:47) ==11962==by 0x1BD7F283: update_program (state.c:945) ==11962==by 0x1BD7F2C5: _mesa_update_state (state.c:976) ==11962==by 0x1BD32F91: radeonMakeCurrent (radeon_context.c:294) ==11962==by 0x1BD2EF24: DoBindContext (dri_util.c:515) ==11962==by 0x1BD2EF85: driBindContext3 (dri_util.c:548) ==11962==by 0x1B954821: BindContextWrapper (in /usr/X11R6/lib/libGL.so.1.2) ==11962==by 0x1B954B70: MakeContextCurrent (in /usr/X11R6/lib/libGL.so.1.2) ==11962==by 0x1B954D57: glXMakeCurrent (in /usr/X11R6/lib/libGL.so.1.2) ==11962==by 0x804B7EF: make_window (in /usr/X11R6/bin/glxgears) So apparently we never free programs.. Also, there is a small leak in DRI Hash code: ==11962== 28 bytes in 1 blocks are definitely lost in loss record 21 of 55 ==11962==at 0x1B9042E8: malloc (vg_replace_malloc.c:130) ==11962==by 0x1B96045B: drmMalloc (in /usr/X11R6/lib/libGL.so.1.2) ==11962==by 0x1B962D20: drmRandomCreate (in /usr/X11R6/lib/libGL.so.1.2) ==11962==by 0x1B96297B: HashHash (in /usr/X11R6/lib/libGL.so.1.2) ==11962==by 0x1B962AA4: HashFind (in /usr/X11R6/lib/libGL.so.1.2) ==11962==by 0x1B962B2C: drmHashLookup (in /usr/X11R6/lib/libGL.so.1.2) ==11962==by 0x1BD2EC4A: __driFindDrawable (dri_util.c:238) ==11962==by 0x1BD2EDD3: DoBindContext (dri_util.c:448) ==11962==by 0x1BD2EF85: driBindContext3 (dri_util.c:548) ==11962==by 0x1B954821: BindContextWrapper (in /usr/X11R6/lib/libGL.so.1.2) ==11962==by 0x1B954B70: MakeContextCurrent (in /usr/X11R6/lib/libGL.so.1.2) ==11962==by 0x1B954D57: glXMakeCurrent (in /usr/X11R6/lib/libGL.so.1.2) best Vladimir Dergachev --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R300 memory leak
does not print many Hello's so this is not the actual culprit.. Does anyone have suggestions ? 'key' is never freed when existing key is found at _mesa_UpdateTexEnvProgram / _tnl_UpdateFixedFunctionProgram. Sorry, forgot to report this one... Great, thank you ! Unfortunately, I can't test it - some of the very latest changes to Mesa completely broke R300 driver - glxgears crashes and Quake has broken textures. Probably something to do with function table improvements. best Vladimir Dergachev -- Aapo Tahkola --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: CVS access
On Sun, 31 Jul 2005, Dave Airlie wrote: I pinged daniel and he seems to have fixed it.. it is the same a/c you us to work on xorg... Everything works - great ! Thanks Dave, Daniel ! Vladimir Dergachev --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] Scrambled fonts
On Tue, 26 Jul 2005, Mark Ferry wrote: Section Device Identifier Card0_r300 Driver ati BusID PCI:0:16:0 Option UseFBDev true # [bool] Option DMAForXV off # [bool] ^ AFAIK, DMAForXv should work fine, at least for people with lowendian hardware. best Vladimir Dergachev Option XaaNoScanlineImageWriteRect Option XaaNoScanlineCPUToScreenColorExpandFill EndSection PS: Does this belong to this ML or to dri-user? Probably dri-user... ciao Mark --- Powerbook5,2 - 1.25GHz 15 G4 Alubook, Radeon 9600 M10 ___ Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] Scrambled fonts
On Tue, 26 Jul 2005, Alex Deucher wrote: On 7/26/05, Vladimir Dergachev [EMAIL PROTECTED] wrote: On Tue, 26 Jul 2005, Mark Ferry wrote: Section Device Identifier Card0_r300 Driver ati BusID PCI:0:16:0 Option UseFBDev true # [bool] Option DMAForXV off # [bool] ^ AFAIK, DMAForXv should work fine, at least for people with lowendian hardware. Should work on bigendian too. I think Michel worked on the patch on PPC initially. There is an issue with R300 and later cards where a command used to to DMA with proper conversion does not work that way anymore. This command is not used in that way for 3d rendering, but is used for DMAForXv. I am not certain whether this was fixed or not. best Vladimir Dergachev Alex --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: I need the R200 to work!
On Tue, 26 Jul 2005, Alan Grimes wrote: Hello, I need my ATI R9250 based board to work because I need it for RD work. -- possibly even remunitive RD work =\ I managed to get the Mesa CVS sources to work but it caused my critical application ( www.croquetproject.org ) to hang... (run it with unix Squeak VM 3.7-7 from www.squeak.org ) On my distribution's default driver. -- and it is a bitch to switch back and forth!, even with opengl-config, the driver will work with any of the VR worlds that DON'T involve a portal to another world... As soon as a portal is put in, it crashes.. -- these portals caused my R128 to crawl!!! =\ Alan, a little more information please ! What OpenGL features/extensions does your application use ? Can you try turning them on and off ? Does it work with sofware rendering ? Why did you download Mesa from CVS instead of using stock distribution - R200 had OpenGL support for a long while now. best Vladimir Dergachev I really don't understand the information flows within the Mesa driver.. How do I tell which parts of the code are in use on my platform and which are only for software rendering? I'd also like my Mach64 to work concurrently with the R200 driver so that I have something to fall back on... =\ -- Friends don't let friends use GCC 3.4.4 GCC 3.3.6 produces code that's twice as fast on x86! --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: radeon driver stops C3 if DRI is enabled
Is there something that can be done to fix this? Not sure; bus mastering is used for sending commands to the GPU when the DRI is enabled (I wouldn't exactly call that 'pointless'...), but that shouldn't be going on all the time, unless e.g. a client that rarely (but regularly) redraws parts of its windows is enough to prevent the CPU from entering C3? Either way, it would be very useful if you could somehow determine exactly what the guilty bus mastering cycles do. I think a clock or similar applet might do this - if it has to redraw pictures it might use bus mastering to upload them. Lorenzo - the reason for using bus mastering for this is that it really is a few times faster than regular way. best Vladimir Dergachev -- Earthling Michel D??nzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
R300 CVS move
Hi all, Both R300 drm and Mesa code has been imported into main CVS repositories on freedesktop.org (drm and mesa3d correspondingly) Big thanks go to Eric Anholt :) While the CVS on r300.sf.net will remain open for anyone to experiment with, I would suggest that r300 developers get freedesktop.org accounts and access to DRM and Mesa3d CVS repositories. This has several advantages: * your latest code is available for wider testing * there is no hassle of synchronizing Mesa, DRM and R300.sf.net source code * you work directly with the main repositories for DRM and Mesa. best Vladimir Dergachev --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
R300 drm patch
Hi all, Here is a first cut at patch against mainline DRM CVS to add R300 support. Notes: * the tarball includes a regular patch and two files that need to be added to drm/shared-core directory * the patch includes changes to BSD code as well - these need to be checked by people familiar with the platform thank you ! Vladimir Dergachev r300drm.tgz Description: Binary data
Re: R300 DRI report
I'm planning to do some benchmarks when ATI update their driver to work with the new xorg release. Any sugestions for some benckmarks that I can run? I'll post the results to the mailing list if people are interested? glxgears is the easy one :) You could also try FlightGear as far as games go. There is also some general OpenGL benchmarking suite (forgot the name), it might be relatively easy to setup. Thanks Sander PS: Is this the correct list to be asking these kind of thing? The r300 website has no refference to a forum or other mailing list then this one. Yep, this is the right mailing list. best Vladimir Dergachev --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R300 DRI report
On Mon, 11 Jul 2005, Sander Sweers wrote: Hi, I have been trying the r300 driver with kernel 2.6.12 and xorg 6.8.99.8 and i have to say I'm impressed :) I have been playing with xscreensaver and am getting +/- 16 fps with a cpu (amd64 3200) load of 50%. I am running gentoo 2005.0/multilib. I have an asus 9600se/td and it is a r300 but not know, reporting it as asked. Unknown device ID 4151, please report. Assuming plain R300. IRQ's not enabled, falling back to busy waits: 15 2 0 this is coming from r300_driver/r300/radeon_screen.c - could check whether using RADEON_CHIP_RV350 works any better for you ? thank you ! Vladimir Dergachev Below is what dmesg reports: [drm] Initialized drm 1.0.0 20040925 PCI: Unable to reserve mem region #1:[EMAIL PROTECTED] for device :01:00.0 mtrr: 0xd000,0x1000 overlaps existing 0xd000,0x800 [drm] Initialized radeon 1.15.0 20050208 on minor 0: ATI Technologies Inc RV350 AQ [Radeon 9600] [drm] Used old pci detect: framebuffer loaded And some warning while is was playing with xscreensaver: *WARN_ONCE* File r300_state.c function r300Enable line 456 TODO - double side stencil ! *** No ctx-FragmentProgram._Current!! *WARN_ONCE* File r300_render.c function r300_get_num_verts line 192 user error: 33 is not a valid number of vertices for primitive QS ! *** *WARN_ONCE* File r300_render.c function r300_get_num_verts line 187 user error: Need more than 1 vertices to draw primitive TS ! *** r300_check_render: fallback:ctx-Point.SmoothFlag (over and over again). If you need me to provide more info or try something let me know. Keep up the good work :) Thanks Sander --- This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual core and dual graphics technology at this free one hour event hosted by HP, AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel --- This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual core and dual graphics technology at this free one hour event hosted by HP, AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Current DRM CVS ?
Hi all, Would anyone know which DRM CVS tree I should submit patches against ? I wanted to give a try at making a patch with R300 DRM driver changes as the source has mostly stabilized. thank you ! Vladimir Dergachev --- This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual core and dual graphics technology at this free one hour event hosted by HP, AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Current DRM CVS ?
On Mon, 11 Jul 2005, Adam Jackson wrote: On Monday 11 July 2005 11:01, Vladimir Dergachev wrote: Hi all, Would anyone know which DRM CVS tree I should submit patches against ? I wanted to give a try at making a patch with R300 DRM driver changes as the source has mostly stabilized. I didn't know there was more than one. /cvs/dri co drm Thank you ! What about code that Jon is working on ? Is it in ? best Vladimir Dergachev - ajax --- This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual core and dual graphics technology at this free one hour event hosted by HP, AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: ATI Mobility 9700 and DGA
On Wed, 6 Jul 2005, Nguyen The Toan wrote: Hi guys, I installed r300_driver and have problems with DGA. One major application I used is xmame, which runs fastest in DGA mode but it complains XDGAOpenFramebuffer failed Is it a bug with the r300 driver ? or I did something wrong. The Xorg.0.log does not give any errors. xpdyinfo shows XFree86-DGA extension is available. This might be an issue not with r300_driver, but rather with newer X.org xserver that you installed. Do any of these errors go away if you recompile ? best Vladimir Dergachev xmame also gives segmentation fault in Xv mode (but xine runs fine with Xv mode). Odd. Thanks, Toan --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Lockup with radeon.ko from r300 when the server starts
On Mon, 4 Jul 2005, Tino Keitel wrote: On Mon, Jul 04, 2005 at 14:01:12 +0200, Jerome Glisse wrote: Is this a hard lockup or not ? ie could you ssh in the box ? Yes, it's a hard lockup. If you can ssh to the box, could you provide Xorg log (in /var/log/) revealent part of syslog or whatever is the ouput of radeon module when you try to start Xserver with it. Maybe you could try to first load radeon module then Xserver, if you don't already try this. When I load the radeon module on the command line everything works. The lockup occurs when the server starts. How very interesting :) I load the module from rc.local during boot, which should be equivalent to the command line. Is there any way for you to use serial console to see what is going on ? You would need a second computer and a serial cable. best Vladimir Dergachev Btw a depmod -a shouldn't hurt, and do a find /lib/modules -name radeon.ko to see if there isn't two copy of it in different places. $ /sbin/modprobe -l | grep radeon /lib/modules/2.6.12/kernel/drivers/char/drm/radeon.ko Regards, Tino --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] drm driver: merge upstream, security, etc
elementary operation and construct a model that would describe performance ? This is not a trivial task as we access the card through, essentially, a batch interface which would make it hard to time elementary operations by themselves with good precision (say 5% ?). Need to get past Mesas array caches and other funnies. To get to that we need true hw VBO's and we cannot even dream of them until Mesa allows us to support native unsigned char colors. One could just access the hardware directly for purposes of such measurement. best Vladimir Dergachev --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] drm driver: merge upstream, security, etc
we may not be able to prevent all such cases doesn't mean we shouldn't prevent the ones we can. Without VPU recovery, it is very likely that the prices would be too high to stand. I really mean 'the ones we can'. All I'm saying is that we should try to prevent it whenever reasonably possible and that the fact that it may not always be is IMHO a bad excuse for never trying. Im looking at the whole picture here. I dont really think we have enough manpower and interest of finishing this kind of boring task using the most difficult approach available. I would like to disagree with you both (Aapo and Michel) :) 1. In order to systematically prevent lockups we need to know what lockups the card is susceptible to. Right now we cannot even find a cause of particular lockup with Radeon 9800 cards, let alone be certain that any usage of particular registers is valid. We do know which registers control access to system memory and this we control tightly. 2. The issue of making sure no lockups exists will appear a lot less boring if put in a different context: Can we measure how long it takes the card to perform certain elementary operation and construct a model that would describe performance ? This is not a trivial task as we access the card through, essentially, a batch interface which would make it hard to time elementary operations by themselves with good precision (say 5% ?). Why bother with such project ? 1. Characterizing such a complex black-box device is not trivial and whatever automation techniques will be invented should prove useful for other things 2. Right now we ignore issues like sharing of memory bandwidth with CRTC or overlay. Knowing timing will allow to fine-tune the raw performance of the driver. 3. It would be interesting to see whether one can do real-time rendering - not in the sense of playing real-time game, but in the sense of issuing a drawing operation and knowing exactly when it completes. best Vladimir Dergachev -- Aapo Tahkola --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r300 on Thinkpad r50p (RV350)
On Wed, 29 Jun 2005, Hamish Marson wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hamish Marson wrote: Just as a status report... On my thinkpad r50p which has an rv350 (FireGL-T2) when using the current CVS xorg, CVS Mesa and the tagged r300 driver 'the_perfect_frag') it all works, 1600fps on glxgears, but the flickering is awful on OpenGL apps... What is your screen depth - 32bpp or 16bpp ? best Vladimir Dergachev (Current CVS is yesterday for xorg, today for Mesa). glxgears - works OK. But flickers. tuxracer - works OK. Reasonable frame rates. But flickers at about 10Hz. gl-117 - Same. Reasonable frame rates. But flickers. glxgears was in a window. tuxracer and gl-117 were full-screen. I had to stop before I threw up... Suspend Resume worked OK so far (Only suspended to RAM once though). Hamish. FWIW the same things also happens on the current CVS copy. This is with a 1600x1200 resolution LCD as well, just in case it matters. gl-117 seems to geta round 60fps in the init screens... But I can't see the screen well enough to navigate through (Or access even) any setup screens to try change anything in it. H - --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click - -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCwgQq/3QXwQQkZYwRAi/5AJ9te9GGyl8xuUXr1GO1pbtPWUPudwCgz6Fe sVVmhSgFAHZI5l0MFLyE2YI= =qw+H -END PGP SIGNATURE- --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
80 column format
I have been going through R300 drm source trying to implement all the
suggestions that people offerred.
I am having some hard time with 80 column rule. Now, in general, I agree
with it and it makes sense. However take a look at the following piece of
code:
/ snip * line 264 r300_cmdbuf.c /
for(i=0;isz;i++){
values[i]=((int __user*)cmdbuf-buf)[i];
switch(r300_reg_flags[(reg2)+i]){
case MARK_SAFE:
break;
case MARK_CHECK_OFFSET:
if(r300_check_offset(dev_priv, (u32)values[i])){
DRM_ERROR(Offset failed range check
(reg=%04x sz=%d)\n, reg, sz);
return DRM_ERR(EINVAL);
}
break;
/ snip /
To me it looks perfectly fine - we have a for cycle, a switch statement
inside and an error check in one of switch statement clauses. I don't see
how separating these out into other functions is going to improve
readability.
Problem is that there is no sane way I can fit the error message in 80
columns without being cryptic.
Any ideas ?
thank you !
Vladimir Dergachev
---
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[R300] drm driver: merge upstream, security, etc
Hi all, I have fixed known issues with r300 DRM driver: * r300_emit_unchecked_state properly fallbacks to r300_emit_carefully_checked_state() when asked to set touchy registers (i.e. those with offsets). * r300_emit_raw properly checks LOAD_VBPNTR packet that all offsets are ok. * all of these copy user data exactly once. The next step is to discuss what else is needed for successful merge into the main DRM CVS. * What are the requirements for a patch to be accepted ? * Can R300 developers get CVS access ? * What else do we need in R300 DRM module ? (Besides working PCIE - Dave what are wishes in this regard ?) * any issues that I missed ? thank you ! Vladimir Dergachev --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] drm driver: merge upstream, security, etc
I was just looking at r300 code today for my own system. A few things that I think ought to happen for the merge: - Clean up style. Unindented blocks of code, weird whitespace (closing brackets on the same column as the block containing it, rather than the surrounding block), lack of wrapping at 80 columns, etc. - r300_emit_unchecked_state should get renamed (r300_check_and_emit_state?) and its all-caps warnings removed. What about r300_emit_packet0 instead of r300_emit_unchecked_state and r300_emit_packet3 instead of r300_emit_raw ? Cause that's what they do. Things I noticed that aren't top priority: - DRM_COPY_FROM_USER_UNCHECKED in r300_emit_cliprects should be a DRM_COPY_FROM_USER, I think. Hmm.. I have no idea either - could anyone else comment ? - Axe the comment about can't afford to let userspace control something that locks up the graphics card so easily in R300_CMD_END3D handling. There are too many ways to hang a graphics card with DRI for us to try to stop the user from doing so. Well, nothing wrong for setting goals too high, at least there is something to look up to ;) - r300_reg_flags should probably be in the dev_priv rather than a global. It is for all practical purposes a static array - identical for each r300 device. No reason to waste memory if someone has two cards. And something I've wondered about for a while: - Is the __user annotation supposed to mean this is a value from userland that should be checked for use or this is a pointer to somewhere in userland that needs to be copy_from_usered before use? No idea, someone else should comment on this.. For the client driver code, I'm thinking it would be a good idea to repocopy it over (thus maintaining CVS history). If you agree with this, whenever its time to do that merge we should have a 1-day rest so that sf.net will make a clean tarball of the current cvsroot, which the sf.net project admin (you) could grab and hand off to me to put the bits in the right place in Mesa CVS. Great, thank you ! Vladimir Dergachev -- Eric Anholt [EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM and permanent SAREA
This lets new non-root apps avoid calling AddMap for sarea. The AddMap call has to stay marked as root only. Any objections to why this won't work? I think this is a good idea, though it might be better to allow each separate DRM driver its own SAREA size. Since drm drivers and Mesa 3d drivers have to match or at least know about each other the number can be hardcoded in DRM driver. best Vladimir Dergachev -- Jon Smirl [EMAIL PROTECTED] --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[R300] securing r300 drm
Now that the driver paints usable pictures without lockups on many cards, including AGP versions of X800 and Mobility M10, it would make sense to ready it for inclusion into main DRI codebase. I do not think that elusive lockups of Radeon 9800 cards, or issues with PowerPC will require any drastic changes. As we discussed earlier, the major reason against inclusion into mainstream DRI CVS is that the driver is not secure in its current state. Below, I will attempt to list current known issues - please reply with your additions. * r300_emit_unchecked_state - it is not as unchecked as it has been initially, however a few poorly checked registers remain: from r300_cmdbuf.c: ADD_RANGE(R300_RB3D_COLOROFFSET0, 1); /* Dangerous */ ADD_RANGE(R300_RB3D_COLORPITCH0, 1); /* Dangerous */ /* .. snip ... */ ADD_RANGE(R300_RB3D_DEPTHOFFSET, 2); /* Dangerous */ In principle an attacker can set these to point to AGP or system RAM and then cause a paint operation to overwrite particular memory range. Ideally we should check that these point inside the framebuffer, i.e. are within range specified by MC_FB_LOCATION register. /* Texture offset is dangerous and needs more checking */ ADD_RANGE(R300_TX_OFFSET_0, 16); I don't think texture offsets are ever written to, however if they point in the wrong place they can be used to read memory directly. ideally we would check these to be either with MC_FB_LOCATION or MC_AGP_LOCATION ranges. Problem is what do we do on PCI cards ? use AIC controller settings ? * r300_emit_raw - we do not have code that checks any of bufferred 3d packets, in particular VBUF_2, IMMD_2, INDX_2 and INDX_BUFFER. I think that none of these can be exploited except to cause a lockup - please correct me if I am wrong * r300_emit_raw - RADEON_3D_LOAD_VBPNTR - this sets offsets and so like texture offset registers could be exploited to read protected memory locations. Again, we need to check the offsets against something reasonable. * anything I forgot ? best Vladimir Dergachev --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM and permanent SAREA
driver out of it. Exactly. v4l is basically just an analog video capture API. It would be nice to have a v4l compatible interface to the radeon capture interface for AIW and VIVO cards; this would require the drm as well. That's another potential user. The radeon v4l driver km is now maintained and developed by Antti Ajanki. The cooperation of drm is needed for acknowledging interrupts, otherwise they are pretty much orthogonal - km uses RADEON_GUI_DMA registers for transfers from video memory to system ram. best Vladimir Dergachev Alex XvMC is very similar to OpenGL in it's use of the hardware. It uses the same DMA command engine and it renders directly to the frame buffer, either to an offscreen area which is then communicated to the video engines, or directly to the visible frame-buffer and hence needs the DRI drawable management. There is very little logical difference between render this texture or render this macroblock. Besides, if V4L needs to use the same DMA command engine it still would need to talk to DRM. Still, this isn't really the point. I'd like to see drm available for other applications than OpenGL in the future. If drmAddMap goes away, I can live with that, but I'd probably would have to implement a device-specific non-root Hi, I'm the master, get me a handle to clean sarea that other clients can map IOCTL when it's needed, and, as I see it, that wouldn't interfer with your work. /Thomas -- Jon Smirl [EMAIL PROTECTED] --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] securing r300 drm
On Tue, 21 Jun 2005, Eric Anholt wrote: On Tue, 2005-06-21 at 14:57 -0400, Vladimir Dergachev wrote: /* Texture offset is dangerous and needs more checking */ ADD_RANGE(R300_TX_OFFSET_0, 16); I don't think texture offsets are ever written to, however if they point in the wrong place they can be used to read memory directly. ideally we would check these to be either with MC_FB_LOCATION or MC_AGP_LOCATION ranges. Problem is what do we do on PCI cards ? use AIC controller settings ? Just verify that the location is within expected areas of the card's virtual address space, like you do for color/depth offsets, right? Yes, the question is what these are for PCI cards. I guess AIC should have a register similar to MC_AGP_LOCATION. best Vladimir Dergachev -- Eric Anholt [EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300/ppc] lockups
On Sat, 18 Jun 2005, Johannes Berg wrote: Hi, I just tried the latest r300 cvs code (with current mesa cvs, latest Xorg snapshot) but all I get is a lockup as soon as the X server starts. If I have debugging enabled, I get a loop of radeon_do_cp_idle calls. Hardware is: :00:10.0 VGA compatible controller: ATI Technologies Inc RV350 [Mobility Radeon 9600 M10] (prog-if 00 [VGA]) Subsystem: ATI Technologies Inc RV350 [Mobility Radeon 9600 M10] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- Latency: 255 (2000ns min), Cache Line Size: 0x08 (32 bytes) Interrupt: pin A routed to IRQ 48 Region 0: Memory at b800 (32-bit, prefetchable) [size=128M] Region 1: I/O ports at 802400 [size=256] Region 2: Memory at b000 (32-bit, non-prefetchable) [size=64K] Expansion ROM at f100 [disabled] [size=128K] Capabilities: [58] AGP version 2.0 Status: RQ=80 Iso- ArqSz=0 Cal=0 SBA+ ITACoh- GART64- HTrans- 64bit- FW+ AGP3- Rate=x1,x2,x4 Command: RQ=1 ArqSz=0 Cal=0 SBA+ AGP- GART64- 64bit- FW- Rate=none Capabilities: [50] Power Management version 2 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Any idea where I should start looking for the source of the lockups or what else to do? The problem is likely either due to the radeon memory controller - in particular registers like MC_FB_LOCATION MC_AGP_LOCATION - or some sort of AGP issue with ring buffer not working properly. The 2d support should work - the fact that it does not indicates a screw up someplace obvious. Check that the registers mentioned above are programmed to what Xserver and drm driver think they are. In particular look for endianness errors, though this might not be it.. To avoid lockups you can modify Xserver code to put exit(0) just after those are set - you will need a separate box to ssh in as the monitor will not be in a usable state. best Vladimir Dergachev Thanks, johannes --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: radeon DST_LINE
On Sat, 18 Jun 2005, Jerome Glisse wrote: Hi, Can anyone provide me some informations on : DST_LINE_START 0x1600 DST_LINE_END 0x1604 (from radeon fb) What they are said to do ? End how to setup them. From the name, I guess that they initiate line drawing in 2d engine. best Vladimir Dergachev Thx a lot. Jerome Glisse --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: radeon DST_LINE
On Sat, 18 Jun 2005, Jerome Glisse wrote: On 6/18/05, Vladimir Dergachev [EMAIL PROTECTED] wrote: On Sat, 18 Jun 2005, Jerome Glisse wrote: Hi, Can anyone provide me some informations on : DST_LINE_START 0x1600 DST_LINE_END 0x1604 (from radeon fb) What they are said to do ? End how to setup them. From the name, I guess that they initiate line drawing in 2d engine. I think it's more than that...but i maybe wrong, depending on value i put in it the lockup on 9800 can take a bit much time to appear...i haven't done statistic on that an thus i could be a feel more than a true a reality... AFAIK initiating a 2d command while 3d engine is active should lead to lockup on Radeons. best Vladimir Dergachev Jerome Glisse --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] suspend/resume and mesa
On Thu, 16 Jun 2005, Jon Smirl wrote: On 6/16/05, Keith Whitwell [EMAIL PROTECTED] wrote: But, if you implement your scheme, by the same logic you need another 512mb of system ram just to make things work. If you've got all that extra ram hanging around, you could implement the single copy scheme and when a suspend occurs, pull the vram back to that extra system ram (which you would have needed anyway), rather than going to disk. The only way to preserve the VRAM contents across suspend/VT swap is to copy it to system RAM. The fbdev drivers can do this, but they don't know what is important in VRAM and what can be regenerated so they just have to copy the whole 512MB (15 seconds). The DRM drivers know what is important but they don't know when suspend/VT swap is happening because there is only one set of kernel hooks and the fbdev driver is attached to them. The scheme where a Stupid question - why can't one add a call to fb to register additional suspend/resume hooks ? This should not be too controversial. best Vladimir Dergachev texture copy is kept in system RAM doesn't depend on the DRM driver having suspend/VT swap hooks since it is able to rebuild VRAM at any point. So, given the way things are now, we have to pick one of the first two choices. Doing anything else (like doing a minimal copy out of VRAM) requires the drivers to be linked. Too many people are opposed to merging DRM/fbdev for that to happen. -- Jon Smirl [EMAIL PROTECTED] --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] suspend/resume and mesa
there is insufficient info about the specific laptop model to know what is failing. It's not like the 12 fbdev drivers are chock full of bugs, they are used routinely on other platforms. You haven't seen intelfb then, it is a train wreck of code and I've no idea if it works on most chipsets, it certainly will blow up with wierd BIOS configs and funny screen, I won't load it on any platform as-is.. Out of curiosity - who are the people that *need* intelfb ? (as opposed to *want*). My impression was that fbdev is necessary only for non-intel folks (like powerpc or sparc owners). best Vladimir Dergachev --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] suspend/resume and mesa
On Thu, 16 Jun 2005, Jon Smirl wrote: On 6/16/05, Benjamin Herrenschmidt [EMAIL PROTECTED] wrote: On Thu, 2005-06-16 at 17:30 -0400, Jon Smirl wrote: On 6/16/05, Vladimir Dergachev [EMAIL PROTECTED] wrote: Out of curiosity - who are the people that *need* intelfb ? (as opposed to *want*). To use Xegl it will require you to load both fbdev and DRM drivers for your hardware. Xegl uses fbdev for things like mode setting. Xegl should use ... EGL. Eventually some other library we define for mode setting on top of it. Xegl should not rely on fbdev directly. Wether the EGL implementation uses fbdev or somethign else on a given platform should be irrelevant to Xegl. Xegl uses OpenGL/EGL, it's not defined to use anything else. It is the mesa implementation of OpenGL/EGL that uses fbdev. Nvidia/ATI will likely provide OpenGL/EGL's that don't use fbdev. One thing that bothers me about this whole discussion is the mounting level of interface complexity. It is not just bad as far as debugging is concerned but will also present a barrier to easy experimentation with the code. Will we have new developers in 5 or 10 years if the interface is so complex that it took several years just to create it ? best Vladimir Dergachev There is also Xglx which is the Xgl server that runs inside X.org using GLX. Xwgl and Xagl will be the windows and apple versions of Xgl whenever they get written. -- Jon Smirl [EMAIL PROTECTED] --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] suspend/resume and mesa
On Fri, 17 Jun 2005, Benjamin Herrenschmidt wrote: Xegl uses OpenGL/EGL, it's not defined to use anything else. It is the mesa implementation of OpenGL/EGL that uses fbdev. Nvidia/ATI will likely provide OpenGL/EGL's that don't use fbdev. One thing that bothers me about this whole discussion is the mounting level of interface complexity. It is not just bad as far as debugging is concerned but will also present a barrier to easy experimentation with the code. Will we have new developers in 5 or 10 years if the interface is so complex that it took several years just to create it ? EGL mode setting interface is very simple. The problem is not the complexity of the interface, more the complexity of the implementation. The interface can be quite simple if it's done right. I am worried not only about kernel-user interface, but also interface between separate parts within the kernel, for example between DRM and fbdev. best Vladimir Dergachev Ben. --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: need help writing driver for SiS m650
On Tue, 12 Jul 2005 [EMAIL PROTECTED] wrote: nVidia gets a lot of flack on their forums from zealous Linux users. (-: I'm glad to see the common customers being minor annoyances... http://www.nvnews.net/vbulletin/showpost.php?p=61077postcount=222 I don't buy the explanation. So what that NVidia drivers are covered by NDA with other companies ? What we really want are the register specs and description of how to program the pipeline. If NVidia *really* wanted to open source their drivers all they had to do is release the register descriptions and watch the drivers appear. If anything, releasing their driver code would spoil the fun of low-level tinkering with powerflux hardware. I do not believe the register specification is covered by NDA, as I cannot imagine that that interface was outsourced. I can see NVidia buying a few cores (say iDCT), but since they are the ones who integrate all that stuff they would have to write their own register interface. Plain and simple, someone there is thinking that locking stuff up is protecting value - whether or not the particular information is of use to any competitors. Which is well described by the proverb about a dog and a heap of hay. best Vladimir Dergachev On Monday 13 June 2005 17:59, Vladimir Dergachev wrote: On Mon, 13 Jun 2005, Benjamin Vander Jagt wrote: I think you're right (and it's a pleasure to meet you, by the way), but the SiS licenses are, as far as I've read them, now protected under two entities instead of just one, so it may be another nVidia case; a company that *wants* to open up but can't. nVidia case ? Would you have a link I can read about that ? I thought nVidia was closed source for other reasons.. best Vladimir Dergachev --- This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput a projector? How fast can you ride your desk chair down the office luge track? If you want to score the big prize, get to know the little guy. Play to win an NEC 61 plasma display: http://www.necitguy.com/?r -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel --- This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput a projector? How fast can you ride your desk chair down the office luge track? If you want to score the big prize, get to know the little guy. Play to win an NEC 61 plasma display: http://www.necitguy.com/?r=20 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: need help writing driver for SiS m650
On Mon, 13 Jun 2005, Benjamin Vander Jagt wrote: I think you're right (and it's a pleasure to meet you, by the way), but the SiS licenses are, as far as I've read them, now protected under two entities instead of just one, so it may be another nVidia case; a company that *wants* to open up but can't. nVidia case ? Would you have a link I can read about that ? I thought nVidia was closed source for other reasons.. best Vladimir Dergachev --- This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput a projector? How fast can you ride your desk chair down the office luge track? If you want to score the big prize, get to know the little guy. Play to win an NEC 61 plasma display: http://www.necitguy.com/?r=20 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] radeon 9800 lockup RADEON_LATENCY
On Sun, 12 Jun 2005, Jerome Glisse wrote: Hi, After many tests and reboot i have a set of register that may influence 9800 lockups. Unfortunetly i don't know how to play with this register as they doesn't seems to be used anywhere (nor X driver, dri, drm if i trust my grep :)) RADEON_LATENCY the most likely to help to resolve the lockup. After a cold reboot i read 0x40 in it. I would like to read 0xff but it seems to be read only and after writing to some random place near it i can't figure out how to setup it. What does this regs do : RADEON_BIOS_6_SCRATCH This is a scratch register - basically just a 32 bit piece of memory. It is used by video BIOS during startup, since BIOS cannot be certain whether main memory have been properly initialized and it is certain that video memory was not. Also, AFAIK, it is used by video BIOS to store some values (perhaps mode information ?) RADEON_MDGPIO_Y_REG On R300 this is a VIP bus register, should have nothing to do with 3d. Also, I would generally suggest to not play with any register with GPIO in the name, unless you have very good reason to. A wrong value written could damage your card. The reason is that GPIO often refers to general purpose input. So if you accidentally enable an output that is used as an input pulled low and then write 1 there you will get a short circuit. best Vladimir Dergachev As this regs appear in radeon reg i hope that some one with the radeon specs on it could give me anyclue on how to play or what is there meanings. Thx Jerome Glisse --- This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput a projector? How fast can you ride your desk chair down the office luge track? If you want to score the big prize, get to know the little guy. Play to win an NEC 61 plasma display: http://www.necitguy.com/?r -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel --- This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput a projector? How fast can you ride your desk chair down the office luge track? If you want to score the big prize, get to know the little guy. Play to win an NEC 61 plasma display: http://www.necitguy.com/?r=20 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] radeon 9800 lockup RADEON_LATENCY
On Sun, 12 Jun 2005, Rune Petersen wrote: Jerome Glisse wrote: On 6/12/05, Rune Petersen [EMAIL PROTECTED] wrote: Jerome Glisse wrote: Does the following differences means that the fglrx driver load another microcode ? Last I checked, Yes. But when reloading r300 (radeon module) the fglrx microcode is overwritten no ? yes. Strictly speaking it is overwritten each time Xserver is restarted, but I guess this has the same effect :) best Vladimir Dergachev Rune Petersen --- This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput a projector? How fast can you ride your desk chair down the office luge track? If you want to score the big prize, get to know the little guy. Play to win an NEC 61 plasma display: http://www.necitguy.com/?r=20 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel --- This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput a projector? How fast can you ride your desk chair down the office luge track? If you want to score the big prize, get to know the little guy. Play to win an NEC 61 plasma display: http://www.necitguy.com/?r=20 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: need help writing driver for SiS m650
On Sun, 12 Jun 2005, Matt Sealey wrote: Someone explain to me why an organised boycott of SiS graphics chips would somehow ENCOURAGE them to help? If all other things have been tried why not ? At least the boycott also makes sure that people who follow it don't have hardware we can't write drivers for. best Vladimir Dergachev PS Is ODW fanless ? Just curious.. Reducing their sales means they have a vat of new excuses for not supporting you. -- Matt Sealey [EMAIL PROTECTED] Manager, Genesi, Developer Relations -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Monday, July 11, 2005 11:54 AM To: Dri-devel@lists.sourceforge.net Cc: [EMAIL PROTECTED] Subject: Re: need help writing driver for SiS m650 I'm rather interested in starting a project to reverse engineer these blasted chips, but I'm somewhat more inclined to start a boycott of them instead. For reverse engineering, I *think* the DLL has an EULA that doesn't let you do any sort of peeking into it, so for legal reasons, we might not be able to go that way. If anyone has more insight into that, it would be welcomed. If there is no easier option, then I was considering just making a FreeDOS-based system and hitting the hardware directly. I used to do that with old video chips, long long ago when I programmed for DOS in Pascal... Hey Benjamin, I have one of these myself and I have tried looking up on reverse engineering the windows xp driver. However I have found it very hard to do so. The driver dll is stripped of all opengl function symbols, and exports only symbols necessary to comply with the ICD architecture. OpenGL drivers on windows are written accordingly to the ICD architecture, which has no open documentation out there. After hearing with microsoft a license for a ICD development kit costs 5000 dollars, and one must have a valid need for it! Do have any plans on making an effort reversing the SiS315? /Cenk On Mon, Jul 11, 2005 at 12:14:55PM -0400, [EMAIL PROTECTED] wrote: I've found myself in the unfortunate ownership of many of these pitiful SiS315-based cards and boards with onboard SiS video. I may be interested in reverse-engineering, as I rather like that sort of tedious work. however, after seeing as much as I have seen from these short-sighted companies, I think an organized boycott of SiS would be more effective for getting our hands on specs, or even a closed-source driver. their chipset quality is already extremely lacking, and they will have a really hard time beating VIA on, well, anything...and VIA is starting to release their stuff open-source! SiS doesn't have much to bargain with. I will help how I can... -Benjamin Vander Jagt --- This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput a projector? How fast can you ride your desk chair down the office luge track? If you want to score the big prize, get to know the little guy. Play to win an NEC 61 plasma display: http://www.necitguy.com/?r -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel --- This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput a projector? How fast can you ride your desk chair down the office luge track? If you want to score the big prize, get to know the little guy. Play to win an NEC 61 plasma display: http://www.necitguy.com/?r=20 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel --- This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput a projector? How fast can you ride your desk chair down the office luge track? If you want to score the big prize, get to know the little guy. Play to win an NEC 61 plasma display: http://www.necitguy.com/?r=20 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] new snapshot ?
On Fri, 10 Jun 2005, Aapo Tahkola wrote:
Someone, I believe it was Aapo, said that they see white lines across the
screen when the framerate is fairly high. I didn't see this up until yesterday
when I had to change from my 9600pro to a 9600XT (I killed the card moving
it between machines somehow).
Are you using SiS based motherboard by any chance?
Following patch should fix this at the cost of some speed...
I just committed the following patch to r300_reg.h:
===
RCS file: /cvsroot/r300/r300_driver/r300/r300_reg.h,v
retrieving revision 1.41
diff -u -r1.41 r300_reg.h
--- r300_reg.h 8 Jun 2005 15:05:24 - 1.41
+++ r300_reg.h 10 Jun 2005 16:09:22 -
@@ -1,6 +1,27 @@
#ifndef _R300_REG_H
#define _R300_REG_H
+#define R300_MC_INIT_MISC_LAT_TIMER0x180
+# define R300_MC_MISC__MC_CPR_INIT_LAT_SHIFT 0
+# define R300_MC_MISC__MC_VF_INIT_LAT_SHIFT 4
+# define R300_MC_MISC__MC_DISP0R_INIT_LAT_SHIFT 8
+# define R300_MC_MISC__MC_DISP1R_INIT_LAT_SHIFT 12
+# define R300_MC_MISC__MC_FIXED_INIT_LAT_SHIFT16
+# define R300_MC_MISC__MC_E2R_INIT_LAT_SHIFT 20
+# define R300_MC_MISC__MC_SAME_PAGE_PRIO_SHIFT24
+# define R300_MC_MISC__MC_GLOBW_INIT_LAT_SHIFT24
+
+
+#define R300_MC_INIT_GFX_LAT_TIMER 0x154
+# define R300_MC_MISC__MC_G3D0R_INIT_LAT_SHIFT0
+# define R300_MC_MISC__MC_G3D1R_INIT_LAT_SHIFT4
+# define R300_MC_MISC__MC_G3D2R_INIT_LAT_SHIFT8
+# define R300_MC_MISC__MC_G3D3R_INIT_LAT_SHIFT12
+# define R300_MC_MISC__MC_TX0R_INIT_LAT_SHIFT 16
+# define R300_MC_MISC__MC_TX1R_INIT_LAT_SHIFT 20
+# define R300_MC_MISC__MC_GLOBR_INIT_LAT_SHIFT24
+# define R300_MC_MISC__MC_GLOBW_FULL_LAT_SHIFT0
+
LAT stands for latency, MC for memory controller.
best
Vladimir Dergachev
--- radeon_driver.c.origFri Jun 10 05:24:35 2005
+++ radeon_driver.c Fri Jun 10 05:46:14 2005
@@ -5631,6 +5631,11 @@
if (!info-IsSecondary)
RADEONChangeSurfaces(pScrn);
+if (info-ChipFamily = CHIP_FAMILY_R300) {
+ unsigned char *RADEONMMIO = info-MMIO;
+ OUTREG(0x180, INREG(0x180) | 0x1100);
+}
+
if(info-MergedFB) {
/* need this here to fix up sarea values */
RADEONAdjustFrameMerged(scrnIndex, pScrn-frameX0, pScrn-frameY0, 0);
--
Aapo Tahkola
---
This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.
Play to win an NEC 61 plasma display: http://www.necitguy.com/?r=20
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
---
This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.
Play to win an NEC 61 plasma display: http://www.necitguy.com/?r=20
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Fwd: radeon YCbCr output
There is an option composite_sync - take a look there. As for Y Cb Cr, I would expect this is implemented as some sort of transform before output. I.e. the chip still thinks it is outputting R, G, B, just weird R G B values. In particular take a look at how gamma support is implemented in the Radeon driver for newer chipsets, it might shed some clues. best Vladimir Dergachev On Mon, 6 Jun 2005, Steven Newbury wrote: --- [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: =?iso-8859-1?B?SSByZWFsaXNlIHRoaXMgaXMgc2xpZ2h0bHkgb2ZmIHRvcGljLCBidXQgSSBmaWd1cmVkIG91dHNpZGUgb2YgQVRJIEknZCBtb3N0DQ==?= =?iso-8859-1?B?bGlrZWx5IGZpbmQgc29tZW9uZSBoZXJlIHdobyBrbm93cy4gSSd2ZSByZWFkIHRoYXQgdGhlIFdpbmRvd3MgZHJpdmVyIGFsbG93cw0=?= =?iso-8859-1?B?Y29tcG9uZW50IHZpZGVvIG91dHB1dCBmb3IgY29ubmVjdGlvbiB0byBUVnMsIHByb2plY3RvcnMgZXRjLiBEb2VzIGFueW9uZSBrbm93DQ==?= =?iso-8859-1?B?d2hhdCByZWdpc3RlcnMgbmVlZCB0byBiZSBzZXQgdG8gd2hhdCB0byBlbmFibGUgdGhpcyBtb2RlPyBJIG5lZWQgdGhlIHN5bmMgb24gWQ0=?= =?iso-8859-1?B?dG9vLiBJJ3ZlIGJlZW4gc2V0dGluZyByYW5kb20gcmVnaXN0ZXJzIGJ1dCBoYXZlbid0IGV2ZW4gbWFuYWdlZCBzeW5jIG9uIGdyZWVuLg0=?= =?iso-8859-1?B?DSAg?= =?iso-8859-1?B?DSAg?= =?iso-8859-1?B?U3RldmUN?= =?iso-8859-1?B?DSAg?= =?iso-8859-1?B?DSAg?= =?iso-8859-1?B?CQkN?= =?iso-8859-1?B?X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18gDQ==?= =?iso-8859-1?B?SG93IG11Y2ggZnJlZSBwaG90byBzdG9yYWdlIGRvIHlvdSBnZXQ/IFN0b3JlIHlvdXIgaG9saWRheSAN?= =?iso-8859-1?B?c25hcHMgZm9yIEZSRUUgd2l0aCBZYWhvbyEgUGhvdG9zIGh0dHA6Ly91ay5waG90b3MueWFob28uY29tDQ==?= Steve ___ Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com --- This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput a projector? How fast can you ride your desk chair down the office luge track? If you want to score the big prize, get to know the little guy. Play to win an NEC 61 plasma display: http://www.necitguy.com/?r=20 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] on lockups
On Sat, 4 Jun 2005, Nicolai Haehnle wrote: The mirroring works as follows: each time scratch register is written the radeon controller uses PCI to write their value to a specific location in system memory. Are you sure it uses PCI? I'm assuming that the destination address for scratch writeback is controlled by the RADEON_SCRATCH_ADDR register. This register is programmed to a value that falls within the AGP area (as defined by RADEON_MC_AGP_LOCATION) if I understand the code correctly. My understanding is that AGP only does transfers system RAM - video RAM and all transfers in the opposite direction have to use plain PCI transfers at least as far as the bus is concerned. It could be that AGP GART can still decode addresses for writes to system memory, I guess this depends on a particular architecture. One of the reasons to look forward to PCI Express is that it is bi-directional, unlike AGP. This, of course, would not work if the memory controller is misprogrammed - which was the cause of failures. Which way can memory controller be misprogrammed ? The part that concerns us are positions of Video RAM, AGP and System Ram in Radeon address space. (these are specified by RADEON_MC_AGP_LOCATION, RADEON_MC_FB_LOCATION). What's the meaning of RADEON_AGP_BASE, by the way? It is programmed to dev-agp-base, which is AFAIK an address from the kernel's address space. That doesn't make much sense to me. It could be anything. However, the recommended way to program the memory controller is to set the BASE of video memory to its physical PCI address and to put AGP memory where it is mirrored by the AGP GART, as, presumably, this does not overlap with system RAM or any of other sensitive areas. My understanding is that dev-agp-base is the address where the AGP GART mirrors the pieces of system RAM comprising AGP space. Of course, these are somewhat bogus on 64 bit system. The memory controller *always* assumes that system RAM (accessible via PCI) starts at 0. So, if RADEON_MC_FB_LOCATION, for example, is set to 0 then we have video RAM overlapping system RAM. However, the size of video RAM is usually much smaller than the size of system RAM. So if the scratch registers image in system memory had small physical address you might get a lockup and if it was high you don't. You also would be more likely to get a lockup when load on system memory increased. Hmm. The way RADEON_MC_(FB|AGP)_LOCATION are programmed, it seems to be like they actually consist of two 16 bit fields, one indicating the start of the FB/AGP area, the other indicating the end. They are always programmed in rather large memory units. Do you know what happens when the programmed size of the FB area is larger than the physical size of video RAM? What happens when the programmed size of the AGP area is larger than the size of the AGP aperture? This problem has been fixed for plain Radeon drivers, but it could be that something similar is manifesting again on R300.. How did that fix work? Eventually the DRM driver was able to reprogram memory controller on request. So by default it used the usual setup (DISPLAY_BASE at 0) and it switched to reasonable setup when requested. The reasons for such behaviour are: * older mesa drivers did not know about reprogramming (and drm is separate from Mesa) * framebuffer does not know about reprogramming * *all* video BIOSes that I have seen always set DISPLAY_BASE to 0. so this is a safe mode (which completely precludes DMA from/to the first N megabytes of system memory where N is the size of video aperture). best Vladimir Dergachev cu, Nicolai --- This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput a projector? How fast can you ride your desk chair down the office luge track? If you want to score the big prize, get to know the little guy. Play to win an NEC 61 plasma display: http://www.necitguy.com/?r=20 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] on lockups
Which way can memory controller be misprogrammed ? The part that concerns us are positions of Video RAM, AGP and System Ram in Radeon address space. (these are specified by RADEON_MC_AGP_LOCATION, RADEON_MC_FB_LOCATION). The memory controller *always* assumes that system RAM (accessible via PCI) starts at 0. So, if RADEON_MC_FB_LOCATION, for example, is set to 0 then we have video RAM overlapping system RAM. Yup, and that is not recommended. We program it differently on r200 but for some reason, X still does that hack to put it down at 0 on r300. I wonder why. I always assumed that r300 should behave similarly to r200 - at least I can't see where the switch is. I certainly have not put any switches to change the behaviour (unless it was a mistake). Note that old driver was able to test whether mirroring works, so it would correspond to behaviour of RV350 cards. It could be that R300 cards are more touchy in this regard. Might be worth trying to fallback to non-mirrored setup and see if that helps. The most puzzling thing is that lockup is not immediate (as I would have expected) and that it works on some chips.. best Vladimir Dergachev Ben. --- This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput a projector? How fast can you ride your desk chair down the office luge track? If you want to score the big prize, get to know the little guy. Play to win an NEC 61 plasma display: http://www.necitguy.com/?r=20 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel --- This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput a projector? How fast can you ride your desk chair down the office luge track? If you want to score the big prize, get to know the little guy. Play to win an NEC 61 plasma display: http://www.necitguy.com/?r=20 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] on lockups
On Sun, 5 Jun 2005, Jerome Glisse wrote: Note that old driver was able to test whether mirroring works, so it would correspond to behaviour of RV350 cards. It could be that R300 cards are more touchy in this regard. Might be worth trying to fallback to non-mirrored setup and see if that helps. Was wondering were this stuff is setup, drm ? Xorg driver ? dri driver ? Or is there a simple option to fallback :) I think this is inside DRM driver. Search for string Writeback doesn't seem to work everywhere, test it first inside the file radeon_cp.c best Vladimir Dergachev Jerome --- This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput a projector? How fast can you ride your desk chair down the office luge track? If you want to score the big prize, get to know the little guy. Play to win an NEC 61 plasma display: http://www.necitguy.com/?r -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel --- This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput a projector? How fast can you ride your desk chair down the office luge track? If you want to score the big prize, get to know the little guy. Play to win an NEC 61 plasma display: http://www.necitguy.com/?r=20 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] on lockups
This register is programmed to a value that falls within the AGP area (as defined by RADEON_MC_AGP_LOCATION) if I understand the code correctly. My understanding is that AGP only does transfers system RAM - video RAM and all transfers in the opposite direction have to use plain PCI transfers at least as far as the bus is concerned. You mean system RAM - graphics card, right? Does this mean that the graphics card cannot always write into memory that falls within RADEON_MC_AGP_LOCATION? I don't think we can rely on this. My understanding is that dev-agp-base is the address where the AGP GART mirrors the pieces of system RAM comprising AGP space. Yes, that's my understanding, too. But what is the Radeon's business knowing that address? Why does it need to know this address? I thought this was CPU address space, not card address space. Yes, however it is convenient to do so. The point is that AGP base address will not normally overlap the location of system RAM. This is, of course, only reasonable for 32 bit systems.. best Vladimir Dergachev cu, Nicolai --- This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput a projector? How fast can you ride your desk chair down the office luge track? If you want to score the big prize, get to know the little guy. Play to win an NEC 61 plasma display: http://www.necitguy.com/?r=20 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] on lockups
Yes, however it is convenient to do so. The point is that AGP base address will not normally overlap the location of system RAM. This is, of course, only reasonable for 32 bit systems.. I understand that part, but it's not what I meant. What I mean is this: You said, RADEON_MC_AGP_LOCATION is used to program where AGP is in the card's address space, and that's all fine and makes sense. However, we are *also* programming dev-agp-base into a register called RADEON_AGP_BASE. What is the meaning of that register? AFAIK this offset is used by PCI GART. When PCI GART is on this offset specifies location of AGP-like space. best Vladimir Dergachev cu, Nicolai --- This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput a projector? How fast can you ride your desk chair down the office luge track? If you want to score the big prize, get to know the little guy. Play to win an NEC 61 plasma display: http://www.necitguy.com/?r=20 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[R300] on lockups
I just wanted to contribute the following piece of information that might help with R300 lockups. I do not know whether it applies or not in this case, but just something to be aware about. Radeon has a memory controller which translates internal address space of the chip into accesses of different memory - framebuffer, agp, system ram. So from the point of view of Radeon chip there is a single flat 32 bit address space which contains everything. This is nice because you can simply set texture offset to a particular number and the chip will pull it from appropriate memory - be it video memory, agp or system ram. (albeit system ram access is done via PCI, not AGP commands and thus is much slower). It used to be that Radeon DRM driver had two modes for usage of scratch registers - a mode when it polled Radeon chip directly and a mode when the contents of the registers were mirrored in the system RAM. The driver would try mirroring during startup and if it fails uses polling method. The mirroring works as follows: each time scratch register is written the radeon controller uses PCI to write their value to a specific location in system memory. This, of course, would not work if the memory controller is misprogrammed - which was the cause of failures. Which way can memory controller be misprogrammed ? The part that concerns us are positions of Video RAM, AGP and System Ram in Radeon address space. (these are specified by RADEON_MC_AGP_LOCATION, RADEON_MC_FB_LOCATION). The memory controller *always* assumes that system RAM (accessible via PCI) starts at 0. So, if RADEON_MC_FB_LOCATION, for example, is set to 0 then we have video RAM overlapping system RAM. However, the size of video RAM is usually much smaller than the size of system RAM. So if the scratch registers image in system memory had small physical address you might get a lockup and if it was high you don't. You also would be more likely to get a lockup when load on system memory increased. This problem has been fixed for plain Radeon drivers, but it could be that something similar is manifesting again on R300.. Note that old driver was able to test whether mirroring works, so it would correspond to behaviour of RV350 cards. It could be that R300 cards are more touchy in this regard. On the other hand, all of this might not be relevant at all.. best Vladimir Dergachev --- This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput a projector? How fast can you ride your desk chair down the office luge track? If you want to score the big prize, get to know the little guy. Play to win an NEC 61 plasma display: http://www.necitguy.com/?r=20 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] [patches] debugging lockups
On Wed, 1 Jun 2005, Adam K Kirchhoff wrote: Nicolai Haehnle wrote: What you can do: Please, test the attached patch.drm-cmdbuf-more-pacifiers, and report if there are any regressions (I don't believe there are any) and/or if it removes certain lockups you are seeing. Well, it's hard for me to judge this patch :-) I played Q3A for just over 20 minutes without a single lockup, something I don't think I've accomplished before. I quit that and then tried UT... Which lasted for all of a minute or two before locking up. I rebooted and tried again and got a lockup after only a few minutes. Are you doing a cold restart ? I would help a lot if you could try this with glxgears and/or quake3: * cold restart * start one of 3d programs measure time before lockup * cold restart * put some memory pressure to mix things up - I would suggest loading a few files in OpenOffice, opening gimp with large pictures, etc, until most of memory is used up. use quiet programs (like word processors or spreadsheets) that can be swapped out. * start one of 3d programs, measure time before lockups. If there is a marked difference, it may have to do with using PCI transfers to write age from scratch registers. thank you ! Vladimir Dergachev --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] [patches] debugging lockups
Adam, Great, thank you very much ! No, the system did not need to be actively swapping in fact this would probably have confused the results. (this is why I asked for passive apps) Could you also let me know the following information: Output of free Output of cat /proc/pci Output of cat /proc/interrupts Output of cat /proc/iomem Anything special about your computer (is it SMP ?) thank you ! Vladimir Dergachev --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r300 bugs
is fun enough :) Also, all of r300 and later cards have more than enough RAM for 32bpp modes. That said, it is probably just a matter of making sure some constants are set properly (like colorbuffer parameters), I don't think anything else in the driver is tied to that. If 16bpp isn't supported, the DDX and/or r300 client driver should be modified not to try, and just fall back to indirect rendering. It think it would be better to put one of the WARN_ONCE messages about the fact that 16bpp is broken and needs to be fixed. Things that are broken and easy to fix are best exposed. best Vladimir Dergachev Keith --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r300 bugs
On Mon, 30 May 2005, Bernhard Rosenkraenzer wrote: Hi, I've just tried out the r300 driver - works remarkably well for untested and broken code. :)) I've run into 2 bugs though: It doesn't work well if the display uses 16 bpp (24 bpp works perfectly) -- 3D in 16 bpp is pretty badly misrendered (sample attached; 2D works well w/ r300 DRI even at 16 bpp) -- mixed with a random section of the rest of the screen, wrong colors, and drawn way too large (but close enough to the expected output to recognize it). I don't think we ever focused on getting 16bpp right - having 32bpp working is fun enough :) Also, all of r300 and later cards have more than enough RAM for 32bpp modes. That said, it is probably just a matter of making sure some constants are set properly (like colorbuffer parameters), I don't think anything else in the driver is tied to that. The 2nd bug is that tuxkart (http://tuxkart.sf.net/) segfaults when starting a game -- apparently the driver is returning a wrong value (or NULL pointer?) somewhere. The game works on r200 and i855; didn't have the time to do a lot of debugging yet. Works fine here - try latest R300 CVS and latest Mesa. I am not playing it fullscreen if this matters any.. best Vladimir Dergachev Any ideas? Thanks, bero --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r300 and pcie card...
On Sun, 29 May 2005, Dave Airlie wrote: Okay I've a Dell Inspiron 6000 with a X300 (1002:5460) on a PCI-Express bus.. I've installed Xorg CVS and the latest r300 drm and with the drm loaded, X hangs the card (usual 99% X server can't kill it ...) turning on debug just gives the usual deadlock ioctl, Is it that bare X that hangs the card or does X work fine with 2d graphics while R300 DRM is loaded ? What are you using for GART ? Could you post messages from it and any diagnostics, I am very curious to see them :) the end of the log is May 29 20:15:51 localhost kernel: [drm:drm_ioctl] pid=8432, cmd=0xc010644d, nr=0x4d, dev 0xe200, auth=1 May 29 20:15:51 localhost kernel: [drm:radeon_cp_indirect] indirect: idx=1 s=0 e=112 d=0 May 29 20:15:51 localhost kernel: [drm:radeon_cp_dispatch_indirect] indirect: buf=1 s=0x0 e=0x70 May 29 20:15:52 localhost kernel: [drm:drm_ioctl] pid=8432, cmd=0x6444, nr=0x44, dev 0xe200, auth=1 May 29 20:15:52 localhost kernel: [drm:radeon_cp_idle] May 29 20:15:52 localhost kernel: [drm:radeon_do_cp_idle] May 29 20:15:52 localhost kernel: [drm:drm_ioctl] ret = fff0 Try without debugging as well. Also, some people have reporting issues the first time the driver is installed, so try again, especially after cold restart (try turning off the notebook and unplugging the battery). Anyone got r300 working on any pci express yet or am I going to have to be the one to try and get it working? You are the first - thank you ! Vladimir Dergachev Regards, Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie Linux kernel - DRI, VAX / pam_smb / ILUG --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r300 radeon 9800 lockup
Are you sure the read pointer is still moving 2mins after the lockup? That would be rather surprising, to say the least. I think I can imagine how this might be happenning. You see a lockup from the driver point of view is when the 3d engine busy bit is constantly on. The read pointer is updated by the CP engine, not the 3d engine. It could be that something would cause the CP engine to loop around sending commands to 3d engine forever. This would keep the 3d engine bit on, update the read pointer and appear to be a lockup to the driver. One way to try to make sure this does not happen is to put code in the DRM driver to control the active size of the ring buffer. Also, there might be an issue where the CP engine expects the ring buffer to be padded with NOPs in a certain way (say to have pointers always on 256 bit boundaries) - I don't think we are doing this. Michel - any chance you could comment ? Thank you ! best Vladimir Dergachev --- SF.Net email is sponsored by: GoToMeeting - the easiest way to collaborate online with coworkers and clients while avoiding the high cost of travel and communications. There is no equipment to buy and you can meet as often as you want. Try it free.http://ads.osdn.com/?ad_id=7402alloc_id=16135op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r300 radeon 9800 lockup
On Wed, 25 May 2005, Nicolai Haehnle wrote: On Wednesday 25 May 2005 17:01, Vladimir Dergachev wrote: Are you sure the read pointer is still moving 2mins after the lockup? That would be rather surprising, to say the least. I think I can imagine how this might be happenning. You see a lockup from the driver point of view is when the 3d engine busy bit is constantly on. The read pointer is updated by the CP engine, not the 3d engine. It could be that something would cause the CP engine to loop around sending commands to 3d engine forever. This would keep the 3d engine bit on, update the read pointer and appear to be a lockup to the driver. What you're saying is, some command that we sent could be misinterpreted by the 3D engine (or we sent something that we didn't intend to send, considering lack of docs etc.) as a command that takes insanely long to complete. No - because then the read pointer would be stationary. The CP engine should not submit commands until the 3d engine busy is 0. (but it reacts faster than we can catch this). My interpretation was that CP engine just keeps submitting the same command to 3d engine, without fetching it and just increases the read pointer all the time. It might help to dump not only read pointer but also the register showing the last command executed. One way to try to make sure this does not happen is to put code in the DRM driver to control the active size of the ring buffer. That could be useful for debugging, but that's about it. The thing is, we *want* to have the ring buffer full. If we didn't want that, we could just make the ring buffer smaller. But that doesn't really *solve* the problem either because even very small commands can take an insane amount of time to finish. I am thinking that there might be a bug where CP engine does something funny when the ring buffer is completely full. Maybe we need to keep a small chunk of space open so that start and end pointers are different. In any case, it would be interesting to know how fast the RPTR still moves and if it becomes unstuck at some point. You also need to watch out for when the X server finally decides to reset the CP. I believe there's a bug where the X server waits much longer than intended to do this, but the reset could still mess with results if you're waiting for too long. Yep. best Vladimir Dergachev --- SF.Net email is sponsored by: GoToMeeting - the easiest way to collaborate online with coworkers and clients while avoiding the high cost of travel and communications. There is no equipment to buy and you can meet as often as you want. Try it free.http://ads.osdn.com/?ad_id=7402alloc_id=16135op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r300 radeon 9800 lockup
On Wed, 25 May 2005, Michel [ISO-8859-1] Der wrote: On Wed, 2005-05-25 at 11:58 -0400, Vladimir Dergachev wrote: I am thinking that there might be a bug where CP engine does something funny when the ring buffer is completely full. Maybe we need to keep a small chunk of space open so that start and end pointers are different. WPTR == RPTR means the ring is empty, if you mean that. The DRM handles that though, unless you made r300 specific changes to the ring handling. (I don't think that RBBM_STATUS would indicate the CP being busy in that case, anyway) No there are no R300 specific modifications as far as I know. But could it be that a malformed command at the very end of the buffer would cause CP engine to spin ? For example what if a command spans WPTR ? thank you Vladimir Dergachev -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer
Re: r300 radeon 9800 lockup
WPTR == RPTR means the ring is empty, if you mean that. The DRM handles that though, unless you made r300 specific changes to the ring handling. (I don't think that RBBM_STATUS would indicate the CP being busy in that case, anyway) No there are no R300 specific modifications as far as I know. But could it be that a malformed command at the very end of the buffer would cause CP engine to spin ? For example what if a command spans WPTR ? You mean that you think you've written a complete (set of) command(s), but the CP interprets it differently? That would be possible I think, but again, do you emit any r300 specific commands to the ring? What do you mean by r300 specific ? We access registers that are r300 specific and use *_2 versions of 3d commands (the ones one field shorter) but that's it. best Vladimir Dergachev -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer
Re: [R300] the_perfect_frag snapshot
On Mon, 23 May 2005, Vladimir Dergachev wrote: On Mon, 23 May 2005, Dario Laera wrote: Hi, I'm doing some test with this driver, and I read on the website that Radeon 9600 (including Radeon Mobility M10) - works well, no lockups... well, not for me :P Exactly, I can play almost every 3d game avaible for linux/PPC, but I get lockups when not in full screen mode. In window mode moving the mouse is a risk, from glxgears to neverball. I remember this problem was discussed some time ago on this list, but don't seems fixed for me. 1. Are you using merged framebuffer ? Try turning it off. 2. Try turning of SilkenMouse - it is one of the options in xorg.conf One more thing - I have DynamicClocks enabled in my xorg.conf - it would be interesting if this has any effect. best Vladimir Dergachev --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] the_perfect_frag snapshot
On Mon, 23 May 2005, Dario Laera wrote: Hi, I'm doing some test with this driver, and I read on the website that Radeon 9600 (including Radeon Mobility M10) - works well, no lockups... well, not for me :P Exactly, I can play almost every 3d game avaible for linux/PPC, but I get lockups when not in full screen mode. In window mode moving the mouse is a risk, from glxgears to neverball. I remember this problem was discussed some time ago on this list, but don't seems fixed for me. 1. Are you using merged framebuffer ? Try turning it off. 2. Try turning of SilkenMouse - it is one of the options in xorg.conf best Vladimir Dergachev Also I have tried playing with some enlightenment cvs apps(I know, unstable code :P), like evas or engage: in gl mode I can only move the mouse, everything is blocked. Dunno if this post can be useful... btw many thanx to all developers of this driver: great work :) Dario -- Laera Dario Undergraduate student at Computer Science University of Bologna ICQ# 203250303 /==/ http://laera.web.cs.unibo.it Mail to: laera_at_cs.unibo.it dario_at_astec.ms --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7412alloc_id=16344op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7412alloc_id=16344op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r300 radeon 9800 lockup
insmod drm.ko debug=1 thank you ! Vladimir Dergachev This is all the output from the drm module with debugging enabled: http://www.visualtech.com/drm.txt.gz Thank you ! By the looks of it the kernel buffer is overflowing with messages. In the past I found useful not to turn drm debugging on, but, rather, insert printk statements in various place in radeon code. This should also provide more information about what is actually going on. Also, it might be interesting to see what happens when you make various calls into NOPs - for example do things work better when you make texture calls into NOPs ? We would not expect the correct output, of course. best Vladimir Dergachev The logging starts with X launching, and ends with UnrealTournament in a lockup. It's about 1.6 megs gzipped, and 54 megs ungzipped, so there's a whole lot of data in there, most of it probably redundant... I haven't had a chane yet to try Aapo's patch against radeon_cursor.c, but I should have some time when I get home this afternoon. Adam --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7412alloc_id=16344op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r300 radeon 9800 lockup
Vladimir Dergachev wrote: In the past I found useful not to turn drm debugging on, but, rather, insert printk statements in various place in radeon code. This should also provide more information about what is actually going on. I can't make any promises. My partner already thinks I spend too much time in front of the computer :-) I'll see what I can do, though. Think a printk statement at the start and end of every function? Have any This is probably overkill and might not be very useful Rather try, at first, to just print a printk logging which command is being executed (r300_cmd.c) - this is not very thorough, but, maybe, there is a pattern. suggestions about what files to start with? Is there some consensus that this is probably a cursor problem now? It is still possible that a cursor problem is triggering a lockup caused by something else - like corrupt command sequence (well, not that easy - I put a rudimentary checker to protect against that, but it could be lack of extra end3d) Also, another cause of lockups could be that we need to insert extra NOPs to have the engine wait a certain time after some operations. I tried experimenting with this earlier with little luck, but maybe someone else would be successful. Lastly, it might be a good idea for someone comfortable with oscilloscope to try to see what could be extracted from power supply lines and such - kinda like using an encephalogram - there could be indications that something is wrong before the trigger. best Vladimir Dergachev Adam --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7412alloc_id=16344op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7412alloc_id=16344op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r300 radeon 9800 lockup
few more minutes before it locked up, but it still locked up rather quickly. I think I remember that there's some way to increase debugging output from the drm module, but can't remember how. I have a serial console, and these lockups rarely take down the whole machine, so I can debug this further if someone wants to point me in the right direction. insmod drm.ko debug=1 thank you ! Vladimir Dergachev Adam --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7412alloc_id=16344op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7412alloc_id=16344op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] the_perfect_frag snapshot
On Sat, 21 May 2005, Rune Petersen wrote: Hi, Vladimir Dergachev wrote: I tagged yesterday the_perfect_frag snapshot of R300 driver. The code is in CVS at http://r300.sf.net As the name suggests I cannot find visible faults with rendering Quake3 levels. Also, PPRacer shows no artifacts either, at least in the first few levels.. Known issues/help needed: * Radeon 9800 cards are still exhibiting an occasional lockup. * It would be interesting to know whether the driver works with some of the newer cards (like Radeon X800) I found to do a little testing on my X800: * Quake3: no artifacts, nice menu =) * Tuxracer: no artifacts * UT 2003: it starts with _many_ artifacts, almost playable in a funny kind of way: I can see items and players, what more do you need? =) * UT 2004: its starts with _many_ artifacts, but locks up in the menu. I'll see if I can pin it down. * a known issue I have is loosing the z-buffer when resizing window - full screen. (I can't figure out why this happens). Thank you very much ! Was this AGP or PCIe version of X800 ? Vladimir Dergachev Rune Petersen --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7412alloc_id=16344op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7412alloc_id=16344op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[R300] the_perfect_frag snapshot
Hi all, I tagged yesterday the_perfect_frag snapshot of R300 driver. The code is in CVS at http://r300.sf.net As the name suggests I cannot find visible faults with rendering Quake3 levels. Also, PPRacer shows no artifacts either, at least in the first few levels.. Known issues/help needed: * Radeon 9800 cards are still exhibiting an occasional lockup. * It would be interesting to know whether the driver works with some of the newer cards (like Radeon X800) * Also see the list at http://r300.sf.net/r300_dri.php Big thanks to everyone who contributed to this release, especially Aapo Tahkola, Ben Skeggs and Nicolai Haehnle ! enjoy ! Vladimir Dergachev --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7412alloc_id=16344op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] the_perfect_frag snapshot
On Fri, 20 May 2005, Adam K Kirchhoff wrote: Vladimir Dergachev wrote: So I can confirm the occaisional lockup with the 9800 still. neverputt played fine for half a round. Q3A played fine for about 8 minutes before locking up my machine. UT played fine for maybe 3-4 minutes before locking up. UT2004 locked up almost immediately in the menu... Which also displayed bizarre... Blender worked! I didn't put it through a lot of tests but I was able to load a number of files which had previously crashed Blender. I'd say there are three things keeping me from switching from my 9000pro to my 9800 permanently: 1) lockups Adam, Could you try the attached patch ? It is unclean, but just in case it does you any good.. thank you ! Vladimir Dergachev No luck. I just tried UT and Q3A... I got in, at most, a few more minutes with each game, if that. Too bad. It would be nice if it worked ;) best Vladimir Dergachev Adam --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7412alloc_id=16344op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
