Re: i945 GM performance question
Brian Paul wrote: > Jonathan Bastien-Filiatrault wrote: > >> Brian Paul wrote: >> >> >>> Jonathan Bastien-Filiatrault wrote: >>> >>> >>>> [snip] >>>> at around 45-50 fps with a 960 face model in zpass mode. >>>> >>>> PS: Have you noticed that some versions of the newer mesa does not >>>> seem to like mixing plain old vertex arrays with VBOs ? The mesa in >>>> Debian unstable(7.0.1) does not segfault on me with direct rendering >>>> with mixed code. >>>> >>>> >>> Are you saying 7.0.1 works as expected but Mesa from git (or the swz >>> branch) doesn't work? I don't quite follow what you're saying. >>> >>> >> Sorry for the non-sequitur. The latest git and the swz branch tend to >> segfault when mixing VBOs with plain old vertex arrays with DRI. This >> problem is not present with the mesa in Debian. Disabling hardware >> acceleration prevents the segfault. I am using the latest DDX and DRM >> code. The kernel is 2.6.22.9 vanilla. The machine is a Dell D620, AMD64. >> Here are the few last lines from valgrind: >> >> ==21659== Invalid read of size 8 >> ==21659==at 0x806F3C9: _tnl_draw_prims (t_draw.c:131) >> ==21659==by 0x8067E83: vbo_exec_DrawArrays (vbo_exec_array.c:259) >> ==21659==by 0x805C413: neutral_DrawArrays (vtxfmt_tmp.h:328) >> ==21659==by 0x41E9D3: OglGeometry::drawShadowVolume(RenderPass >> const&) (geometry.cpp:315) >> ^^ vertex array draw >> ==21659==by 0x41EBE8: OglGeometry::render(RenderPass const&) >> (geometry.cpp:357) >> ==21659==by 0x41697F: Drawable::draw(RenderPass const&) (drawable.h:32) >> ==21659==by 0x4169AF: DrawableObject::draw(RenderPass const&) >> (drawableobject.h:14) >> ==21659==by 0x416DC3: Node::draw(RenderPass const&) (node.cpp:24) >> ==21659==by 0x417BBA: Scene::render() (scene.cpp:111) >> ==21659==by 0x4138FE: Window::draw() (window.cpp:242) >> ==21659==by 0x41393D: Window::draw_cb() (window.cpp:36) >> ==21659==by 0x4C4639A: processWindowWorkList (glut_event.c:1306) >> ==21659== Address 0x1C5D7558 is not stack'd, malloc'd or (recently) free'd >> >> I am pretty sure I am not passing invalid pointers to mesa. Shall I >> write a test case ? Do you want to have a look at the code ? >> > > It would be ideal if you could provide a small test program and file a > bug report. I'm working on tracking down a couple other VBO bugs in > between other things... > > -Brian Due to my inexperience with VBO, I was forgetting to unbind the buffer at the draw mentionned above, doing this does not trigger the segfault, since glVertexPointer now knows where to look. Sorry :-( Jonathan - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: i945 GM performance question
Brian Paul wrote: > Jonathan Bastien-Filiatrault wrote: > >> [snip] >> at around 45-50 fps with a 960 face model in zpass mode. >> >> PS: Have you noticed that some versions of the newer mesa does not seem >> to like mixing plain old vertex arrays with VBOs ? The mesa in Debian >> unstable(7.0.1) does not segfault on me with direct rendering with mixed >> code. >> > > Are you saying 7.0.1 works as expected but Mesa from git (or the swz > branch) doesn't work? I don't quite follow what you're saying. > Sorry for the non-sequitur. The latest git and the swz branch tend to segfault when mixing VBOs with plain old vertex arrays with DRI. This problem is not present with the mesa in Debian. Disabling hardware acceleration prevents the segfault. I am using the latest DDX and DRM code. The kernel is 2.6.22.9 vanilla. The machine is a Dell D620, AMD64. Here are the few last lines from valgrind: ==21659== Invalid read of size 8 ==21659==at 0x806F3C9: _tnl_draw_prims (t_draw.c:131) ==21659==by 0x8067E83: vbo_exec_DrawArrays (vbo_exec_array.c:259) ==21659==by 0x805C413: neutral_DrawArrays (vtxfmt_tmp.h:328) ==21659==by 0x41E9D3: OglGeometry::drawShadowVolume(RenderPass const&) (geometry.cpp:315) ^^ vertex array draw ==21659==by 0x41EBE8: OglGeometry::render(RenderPass const&) (geometry.cpp:357) ==21659==by 0x41697F: Drawable::draw(RenderPass const&) (drawable.h:32) ==21659==by 0x4169AF: DrawableObject::draw(RenderPass const&) (drawableobject.h:14) ==21659==by 0x416DC3: Node::draw(RenderPass const&) (node.cpp:24) ==21659==by 0x417BBA: Scene::render() (scene.cpp:111) ==21659==by 0x4138FE: Window::draw() (window.cpp:242) ==21659==by 0x41393D: Window::draw_cb() (window.cpp:36) ==21659==by 0x4C4639A: processWindowWorkList (glut_event.c:1306) ==21659== Address 0x1C5D7558 is not stack'd, malloc'd or (recently) free'd I am pretty sure I am not passing invalid pointers to mesa. Shall I write a test case ? Do you want to have a look at the code ? >> Is it even worth it putting shadow edge geometry in a VBO ? For >> the light cap, I use glDrawElements with the main vertex VBO, avoiding >> copies of vertex data. >> > > Sometimes, determining the best storage/rendering method depends on the > hardware or other factors so it's best to do actual measurements to > answer the question. > > -Brian Thanks, Jonathan - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: i945 GM performance question
Michel Dänzer wrote: > On Mon, 2007-09-24 at 21:51 -0400, Jonathan Bastien-Filiatrault wrote: > >> I have made a program that draws zfail/zpass shadows. I draw three >> models with ~120 tris each and one light source and a simple floor, with >> zpass. I can get a full 60fps until the window size reaches about >> 780x580 which drops to around ~30 fps in a maximized window (1342x820). >> The application is far from cpu-bound and vsync is disabled. >> >> >> I was wondering if I am really hitting the 945GM fill rate limit, or I >> am doing something terribly costly someway along the way (this should >> not be the case, it is somewhat too simple). I have tried with the >> latest i915 in Debian and the latest i915tex from git (right after it >> got renamed to i915). The newer driver gives a steady ~20 fps, any >> window size, for my program and ~60 fps for glxgears. >> >> >> The render is divided into three passes: ambient, shadow volumes(front >> and back), "illuminate", nothing remarkable. I use VBOs, the performance >> is about the same as vertex arrays (added vbo support for the heck of it >> today). >> > > I'm not sure, but it sounds like this is something the software zone > rendering on the i915tex-zone-rendering branch might help for. You'll > need to set the environment variable INTEL_SWZ=1 to make it use software > zone rendering. Thanks for the tip. I used the zone rendering branch, with the latest DRM (pipes/planes patch applied) and it gives me a boost of around 10 FPS. Disabling lighting and blending during the shadow volume gave me another 10 FPS boost. The biggest optimization was putting the shadow volume geometry and using glDrawArrays. I now run fullscreen (1440x900) at around 45-50 fps with a 960 face model in zpass mode. PS: Have you noticed that some versions of the newer mesa does not seem to like mixing plain old vertex arrays with VBOs ? The mesa in Debian unstable(7.0.1) does not segfault on me with direct rendering with mixed code. Is it even worth it putting shadow edge geometry in a VBO ? For the light cap, I use glDrawElements with the main vertex VBO, avoiding copies of vertex data. Thanks for the help, and the tips, Jonathan - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: moved i915tex
Sergio Monteiro Basto wrote: > Hi I just update all gits: libdrm, drm, mesa and xf86-video-intel > > And now I don't have DRI > > (WW) intel: No matching Device section for instance (BusID PCI:0:2:1) > found > (WW) intel(0): Bad V_BIOS checksum > (WW) intel(0): Register 0x61200 (PP_STATUS) changed from 0xc008 to > 0xd009 > (WW) intel(0): PP_STATUS before: on, ready, sequencing idle > (WW) intel(0): PP_STATUS after: on, ready, sequencing on > (WW) intel(0): Register 0x68080 (TV_FILTER_CTL_1) changed from > 0x885e to 0x800010bb > (WW) intel(0): Register 0x68084 (TV_FILTER_CTL_2) changed from > 0x00012d2d to 0x00028283 > (WW) intel(0): Register 0x68088 (TV_FILTER_CTL_3) changed from > 0x9696 to 0x00014141 > (WW) intel(0): Removed DRI frontbuffer mapping in compatibility mode. > (WW) intel(0): DRIGetDeviceInfo will report incorrect frontbuffer > handle. > (WW) intel(0): ESR is 0x0010, page table error > (WW) intel(0): PGTBL_ER is 0x0010, display A pte > (WW) intel(0): Existing errors found in hardware state. > (WW) intel(0): fbc already enabled on plane a, not enabling on plane a > (EE) AIGLX error: drmMap of framebuffer failed (Invalid argument)(EE) > AIGLX: reverting to software rendering > (WW) intel(0): fbc already enabled on plane a, not enabling on plane a > > > Thanks, > Had the same error today, I think it was caused by mismatched X headers while compiling the DDX. You may also want to make sure there are no old libdrm headers hanging around. Jonathan. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
i945 GM performance question
Hello, I have made a program that draws zfail/zpass shadows. I draw three models with ~120 tris each and one light source and a simple floor, with zpass. I can get a full 60fps until the window size reaches about 780x580 which drops to around ~30 fps in a maximized window (1342x820). The application is far from cpu-bound and vsync is disabled. I was wondering if I am really hitting the 945GM fill rate limit, or I am doing something terribly costly someway along the way (this should not be the case, it is somewhat too simple). I have tried with the latest i915 in Debian and the latest i915tex from git (right after it got renamed to i915). The newer driver gives a steady ~20 fps, any window size, for my program and ~60 fps for glxgears. The render is divided into three passes: ambient, shadow volumes(front and back), "illuminate", nothing remarkable. I use VBOs, the performance is about the same as vertex arrays (added vbo support for the heck of it today). Some benchmarks at 1342x820, zpass: Skipping the front-polygon shadow volume pass: 35fps Skipping not drawing any polygons to the stencil buffer: 53fps Ambient pass only: 88fps Sample renders available at http://www.youtube.com/trektactoe Obviously, shoving the geometry down the pipeline twice is a slowdown, and so are the shadow volumes. Am I expecting too much from this chip ? Can I give a hand in profiling the driver ? Insight appreciated and welcome, Jonathan Bastien-Filiatrault - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] Anisotropic filtering advertised, but not enabled
On Sun, January 14, 2007 13:50, Jerome Glisse said: > On 1/13/07, Jonathan Bastien-Filiatrault <[EMAIL PROTECTED]> wrote: >> >From my tests, it would seem that the r300 driver advertises >> anisotropic >> filtering capability, yet, simple tests clearly show that it is not >> enabled. >> Please note that I am not running the latest Mesa. >> >> OpenGL renderer string: Mesa DRI R300 20060815 AGP 4x TCL >> OpenGL version string: 1.3 Mesa 6.5.1 >> Test program: >> http://steinsoft.net/index.php?site=Programming/Projects/OpenGL/anisotropictest >> >> Thank you for your time, >> Jonathan >> > > I added this to the r300 to do list which is located here: > http://dri.freedesktop.org/wiki/R300ToDo > http://dri.freedesktop.org/wiki/R300 > If you see any other feature missing feel free to add it > there. I try to make this list shrink and i encourage anyone > to come help making it shrinking :). > > best, > Jerome Glisse > I tried to add an entry to the Todo yesterday, it said I was not allowed to write on that page, just a note. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[r300] Anisotropic filtering advertised, but not enabled
>From my tests, it would seem that the r300 driver advertises anisotropic filtering capability, yet, simple tests clearly show that it is not enabled. Please note that I am not running the latest Mesa. OpenGL renderer string: Mesa DRI R300 20060815 AGP 4x TCL OpenGL version string: 1.3 Mesa 6.5.1 Test program: http://steinsoft.net/index.php?site=Programming/Projects/OpenGL/anisotropictest Thank you for your time, Jonathan - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
No more lockups with Radeon 9800 Pro
Just wanted to report that my Radeon now works flawlessly, cheers to the r300 developers !! - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[r128] temporary 3D slowdown and error in driver initialization
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Lately, the 3D driver on my laptop (iBook 2001 dual usb, powerpc, Debian GNU/Linux testing/unstable) has been slowing down in certain conditions. glxgears runs fine, crack-attack has a good framerate until a red 'garbage block' comes down and armagetron is unplayably slow. I have checked my X log, and I found a weird error in it (see below). According to the old XFree86 log that was in the log directory, this error did not occur and had a "decent" framerate in OpenGL games. It would seem X has trouble allocating a range of 256 registers in IO space. I think this regression, if it is one, is younger than 3 months. Thanks for your time, Jonathan Bastien-Filiatrault Versions: drm: 20030725 (vanilla 2.6.16) X: 7.0.0 (latest packaged in debian unstable) dri: libgl1-mesa-dri 6.4.1(-0.4) Driver module loading log: (II) Loading sub module "r128" (II) LoadModule: "r128" (II) Loading /usr/lib/xorg/modules/drivers/r128_drv.so (II) Module r128: vendor="X.Org Foundation" compiled for 7.0.0, module version = 4.0.4 Module class: X.Org Video Driver ABI class: X.Org Video Driver, version 0.8 (WW) INVALID IO ALLOCATION b: 0xf400 e: 0xf4ff correcting^G (EE) end of block range 0xefff < begin 0xf000 (II) window: [0] -1 0 0x - 0x (0x1) IX[B] (II) resSize: (II) window fixed: [0] -1 0 0x - 0x (0x1) IX[B] (II) resource ranges after probing: [0] -1 0 0xffe0 - 0x (0x20) MX[B](B) [1] -1 0 0x0010 - 0x3fff (0x3ff0) MX[B]E(B) [2] -1 0 0x000f - 0x000f (0x1) MX[B] [3] -1 0 0x000c - 0x000e (0x3) MX[B] [4] -1 0 0x - 0x0009 (0xa) MX[B] [5] -1 0 0xf500 - 0xf5000fff (0x1000) MX[B] [6] -1 0 0x8008 - 0x80080fff (0x1000) MX[B] [7] -1 0 0x80081000 - 0x80081fff (0x1000) MX[B] [8] -1 0 0x8000 - 0x8007 (0x8) MX[B] [9] -1 0 0xf100 - 0xf101 (0x2) MX[B](B) [10] -1 0 0x9000 - 0x90003fff (0x4000) MX[B](B) [11] -1 0 0x9400 - 0x97ff (0x400) MX[B](B) [12] 0 0 0x000a - 0x000a (0x1) MS[B] [13] 0 0 0x000b - 0x000b7fff (0x8000) MS[B] [14] 0 0 0x000b8000 - 0x000b (0x8000) MS[B] [15] -1 0 0x0400 - 0x04ff (0x100) IX[B](B) [16] -1 0 0x - 0x (0x1) IX[B] [17] -1 0 0x - 0x00ff (0x100) IX[B] [18] 0 0 0xf3b0 - 0xf3bb (0xc) IS[B] [19] 0 0 0xf3c0 - 0xf3df (0x20) IS[B] (II) Setting vga for screen 0. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFEeSbmt3/zhzyeO3cRAq8FAJsHffxz1gQFTqg+8HRUWiwHKekOWQCfeB/s JRiz0gRTkm/njNOS+Gyu0Co= =XKVW -END PGP SIGNATURE- --- All the advantages of Linux Managed Hosting--Without the Cost and Risk! Fully trained technicians. The highest number of Red Hat certifications in the hosting industry. Fanatical Support. Click to learn more http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: New DRI binary snapshots
Felix Kühling said: > Hello DRI testers, > > I finally got around to bringing the snapshot build up to speed with the > latest changes in the build process and uploaded a first set of new > snapshots to http://dri.freedesktop.org/snapshots/. They are completely > untested so be prepared for problems with the first couple of rounds. > Please report any issues with the snapshots to > [EMAIL PROTECTED] As long as they are problems with the > snapshot build and packaging process I will try to resolve them ASAP. > > The new snapshots also include a package for the experimental R300 > driver. I hope the R300 developers are fine with exposing their work to > a larger audience. ;-) Thank you, building them by hand once in a while gets boring/frustrating as it is non-trivial. > > Best regards, > Felix Cheers, keep up the great work, Jonathan --- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today * Register for a JBoss Training Course Free Certification Exam for All Training Attendees Through End of 2005 Visit http://www.jboss.com/services/certification for more information -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r200 unstable with TCL enabled
Felix Kühling wrote: > Am Freitag, den 07.10.2005, 15:20 + schrieb Jacek Popławski: > >>On Fri, Oct 07, 2005 at 02:25:26PM +0200, khaqq wrote: >> >>>Sounds close enough to what I'm running here, stable too, and I had frequent >>>lockups before (6.8.2). I had noticed the lockups would occur less frequently >>>without TCL. Now it's perfectly stable with or without TCL. >> >>So it is possible to have stable and fast OpenGL with open soruce drivers and >>Radeon (I still can't crash it!). But are there binary snapshots for end users >>available? I found only old ones. xorg is available only as source and >>Mesa/drm >>only as source from CVS. Will http://dri.freedesktop.org/snapshots/ be >>updated? > > > Eventually. I haven't got around to adjusting the snapshot build scripts > to changes in the build process (libGL from Mesa and libdrm via > pkgconfig come to mind). It will be a week before I have time to look > into it (hopefully). You're welcome to beat me to it. ;-) In the > mid-term I intend to build snapshots from the modular tree. But that's a > slightly bigger project. > It would be most appreciated if you would build the r300 driver too, as it would greatly simplify installation for a lot of people. Keep up the great work, Jonathan signature.asc Description: OpenPGP digital signature
Re: [patches] Re: r300 radeon 9800 lockup
Adam K Kirchhoff wrote: > Nicolai Haehnle wrote: > >> Hi everybody, >> >> I once again tripped upon an R300 lockup (possibly the same one that >> everybody's been talking about) and spent the last one and half days >> chasing it down. >> >> It turns out that writing the vertex buffer age to scratch registers >> (the ones that are written back to main memory) during a 3D sequence >> is a bad idea. Apparently, this confuses the memory controller so >> much that some part of the engine locks up hard. >> >> The attached patch.out-of-loop-dispatch-age fixes this, at least for me. >> >> The attached patch.remove-userspace-pacifiers removes additional >> unnecessary emission of the pacifier sequence from the userspace >> driver. Userspace isn't supposed to emit this sequence anyway. >> >> Could everybody please test whether a) the first patch really does >> fix the lockups people are seeing and >> b) whether combining both the first and the second patch causes any >> regressions. >> >> If everything's fine with these patches, I'm going to commit them in >> a few days or so. >> >> cu, >> Nicolai >> > > A) The first patch may help a little, but definitely doesn't eliminate > the lockups. > > B) Huge regression. With both patches I get an immediate lockup when > launching glxgears (before the > window is even drawn). > > Adam > Funny enough, two days ago, I played vegastrike for litterally _hours_ with my Radeon 9800 Pro, both patches applied, I restarted the game a couple times and I could not get it to lockup. However, the day after, I could not even start the game without causing a lockup. Looks like you did something good, keep up the great work. Keep up the good work, I'm sure you guys will figure it out, Jonathan signature.asc Description: OpenPGP digital signature
Re: r300 radeon 9800 lockup
Michel Dänzer wrote: >On Mon, 2005-05-23 at 18:45 +0200, Nicolai Haehnle wrote: > > >>It is equally likely that the lockup is caused by, say, alignment or >>wraparound issues of the ring buffer. >>Note that fglrx always submits commands in indirect buffers, which are >>stored linearly in physical memory. We, on the other hand, always submit >>commands into the ring buffer, which is not linear (because it wraps >>around). Also, fglrx likes to emit NOPs into the command stream sometimes, >>though I haven't been able to find an exact pattern in those NOPs. We never >>emit NOPs (or do we?). >> >>So the fact is: We just don't know whether alignment/wraparound can cause >>trouble. The emission of NOPs by fglrx is IMO significant evidence that >>there *are* issues in this area, at least on some chipsets, but it could >>just be some weird artifact of the fglrx codebase. >> >> > >The NOPs in the ring buffer are there for alignment/performance reasons, >they shouldn't affect lockups either way. > I do not know much about ATI processors, but could they be there to prevent unprotected pipeline stalls/conflicts which could cause lockups ? Would adding 3/4 NOPs after a command to clear the pipeline prevent the lockup ? Cheers, Jonathan signature.asc Description: OpenPGP digital signature
Re: [R300] the_perfect_frag snapshot
Adam K Kirchhoff 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 > 2) lack of S3TC through the libtxc_dxtn > 3) Not being merged into Mesa (and, along with that, lack of FreeBSD > support). > > Is there any way to debug these lockups? > > Adam I have had the exact same problems, I am willing to help debug this, you can find a debug kernel log of a crash at http://dastyle.net/joe/kern.log.bz2. Cheers, Jonathan signature.asc Description: PGP signature signature.asc Description: OpenPGP digital signature
Re: [R300] new snapshot ?
Jerome Glisse wrote: >Right now i am on pixel shader after doing some test i don't think we can >use a similar stuff like i915 emit arithm, i915 hardware are far more easier >to program than r300. I am coding another approach an hope to have it >done by the end of this week. > >Moreover i see that 9800 are reported to crash with the driver ? Is this >still true ? > > I will confirm this tomorrow, right now, I am busy with other stuff. Cheers, Jonathan signature.asc Description: OpenPGP digital signature
Re: r300 Radeon 9800 Pro lockups
Vladimir Dergachev wrote: >>> >>> Can you try if reverting revision 1.6 of radeon_cursor.c in X.org CVS >>> makes a difference? >>> >> Reverting this file to version 1.5 caused the cursor to appear after the >> lockup, I could move it but everything else was fudged. During this >> test, I flipped my mouse over to make sure it would not move. It would >> seem that the cursor is related to the lockups I have experienced. > > > One more suggestion: try turning "SilkenMouse" off. I am not certain > which option does it (I am away at a conference with really poor > internet access), search google and the Xorg manuals. > > Turning this option off might make mouse movements a bit jerkier, but > will improve synchronicity in Xserver access to hardware.. > > I have tried that with no change, this problem does not seem to be mouse-related since I take precautions to get no events from the mouse. Anyway, here is a log of a sample lockup, in my newbie opinion, it would seem to be a locking problem. http://dastyle.net/joe/kern.log.bz2 Cheers, Jonathan signature.asc Description: PGP signature signature.asc Description: OpenPGP digital signature
Re: r300 Radeon 9800 Pro lockups
Michel DÃnzer wrote : >On Thu, 2005-04-14 at 13:36 -0400, Jonathan Bastien-Filiatrault wrote: > > >>I have tried the experimental r300 driver with my Radeon 9800 Pro. >>The rendering speed and accuracy are simply amazing. Unfortunately, I am >>getting random lockups about every five minutes. The Xorg process takes >>100% CPU and I have to reboot to get the graphics card in a usable >>state. The OS besides that seems to be unnafected. If I move the mouse, >>it locks up in a matter of seconds. Could anyone give me pointers/test >>cases to help debug this ? It seems that fixing this lockup would be the >>last little step to have working free software drivers for the ATI >>Radeon line. >> >> > >Can you try if reverting revision 1.6 of radeon_cursor.c in X.org CVS >makes a difference? > Reverting this file to version 1.5 caused the cursor to appear after the lockup, I could move it but everything else was fudged. During this test, I flipped my mouse over to make sure it would not move. It would seem that the cursor is related to the lockups I have experienced. Thanks for your time, Jonathan signature.asc Description: OpenPGP digital signature
Re: r300 Radeon 9800 Pro lockups
khaqq wrote: >On Thu, 14 Apr 2005 13:36:56 -0400 >Jonathan Bastien-Filiatrault <[EMAIL PROTECTED]> wrote: > > > >>Hi list, >> >>I have tried the experimental r300 driver with my Radeon 9800 Pro. >>The rendering speed and accuracy are simply amazing. Unfortunately, I am >>getting random lockups about every five minutes. The Xorg process takes >>100% CPU and I have to reboot to get the graphics card in a usable >>state. The OS besides that seems to be unnafected. If I move the mouse, >>it locks up in a matter of seconds. Could anyone give me pointers/test >>cases to help debug this ? It seems that fixing this lockup would be the >>last little step to have working free software drivers for the ATI >>Radeon line. >> >>Thank you for your time, >>Jonathan >> >> > >Hello, > >Are you using Xorg 6.8.x or CVS ? >CVS might be a good idea, there are fixes for lockups on Radeons... >http://dri.freedesktop.org/wiki/Building <= this may help. > >Cheers > >khaqq > > > > I am using the latest Xorg cvs + Mesa cvs + r300 driver Thanks, Jonathan signature.asc Description: OpenPGP digital signature
r300 Radeon 9800 Pro lockups
Hi list, I have tried the experimental r300 driver with my Radeon 9800 Pro. The rendering speed and accuracy are simply amazing. Unfortunately, I am getting random lockups about every five minutes. The Xorg process takes 100% CPU and I have to reboot to get the graphics card in a usable state. The OS besides that seems to be unnafected. If I move the mouse, it locks up in a matter of seconds. Could anyone give me pointers/test cases to help debug this ? It seems that fixing this lockup would be the last little step to have working free software drivers for the ATI Radeon line. Thank you for your time, Jonathan signature.asc Description: OpenPGP digital signature
What do we need to support Radeon 9200 and up ?
I was wondering if the specs for these cards are legally released/obtainable by the public. I can't even use the proprietary ati driver with XFree 4.4.0. Any insigth is appreciated. -- Happy Hacking, Jonathan signature.asc Description: This is a digitally signed message part
