Re: [Dri-devel] Radeon 7500 Debug
On Mit, 2002-03-20 at 01:02, Jens Owen wrote:
Michel Dänzer wrote:
On Die, 2002-03-19 at 08:22, Jean-Christophe Dubacq wrote:
On Mon, Mar 18, 2002 at 09:18:47PM -0700, Jens Owen wrote:
OK, I compiled the tcl-0-0 branch, installed it, and I still have two
kind of bugs... X suddenly disappearing or hard lockups. How do I set
debugging information ?
http://dri.sourceforge.net/doc/DRIuserguide.html
Thanks for the pointer. However, it happened again, even tough I had set
Option NoAccel True # [bool]
So this may not be the good mailing-list any more.
I will try to use the LIBGL_DEBUG variable. But I am now thinking it
could be a hardware issue.
Very unlikely to be a driver problem indeed, as that option disables any
2D or 3D acceleration.
3D, too? I thought the NoAccel option only disabled 2D hardware
rendering...
From RADEONScreenInit():
if (xf86ReturnOptValBool(info-Options, OPTION_NOACCEL, FALSE)) {
xf86DrvMsg(scrnIndex, X_WARNING,
Acceleration disabled, not initializing the DRI\n);
info-directRenderingEnabled = FALSE;
--
Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer
XFree86 and DRI project member / CS student, Free Software enthusiast
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon 7500 Debug
On Wed, Mar 20, 2002 at 01:03:26PM +0100, Michel Dänzer wrote: I will try to use the LIBGL_DEBUG variable. But I am now thinking it could be a hardware issue. Very unlikely to be a driver problem indeed, as that option disables any 2D or 3D acceleration. I changed my card now. I will see if this remains stable. Btw, the 'pipes' screensaver (from Xscreensaver distribution) still doesn't work (radeon_setcliprect: bad mode, or something like that). Thanks for all your advices. -- Jean-Christophe Dubacq -- ATER en informatique à la faculté d'Orsay. Tel: 01 69 15 76 43 / 06 64 86 10 56 --- Email: [EMAIL PROTECTED] ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] glSamplePass missing in libGL.so (only glSamplePassARB available)
just a quick guess since i am not aware of that specific function... (assumed) its an extension to the OpenGL 1.x standard. extension names arent most often exported by standard lib GL as symbols but only via the get by name method. you might want to have a look at the respective OpenGL specs now. -Original Message- From: Andreas Stenglein [mailto:[EMAIL PROTECTED]] Sent: Wednesday, March 20, 2002 14:32 To: [EMAIL PROTECTED] Subject: [Dri-devel] glSamplePass missing in libGL.so (only glSamplePassARB available) Hello! just discoverd that (in my) libGL.so theres no glSamplePass symbol available. its build from today (2002-03-20) DRI-trunk-code. And its not available in the tcl-0-0-branch, too. strings libGL.so | grep glSamplePass glSamplePassARB regards, Andreas [EMAIL PROTECTED] ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] slow tdfx OpenGL since Mesa-4.0.1
After I compiled XFree86 CVS with Mesa-4.0.1 - OpenGL slowed down. I tested it in RTCW, Quake, and my own programs. Of course acceleration is on, but fps dropped down. So I compiled DRI from CVS, but nothing changes - OpenGL is still slower. Is it normal, or did I break something? I have Voodoo3 2000, K6-2 500, Linux-2.4.19-pre1-ac1 and glibc-2.1.3. -- decopter - free SDL/OpenGL simulator under heavy development download it from http://decopter.sourceforge.net ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] S3 Virge DRI completed (almost)
On Wednesday 20 March 2002 14:07, you wrote: hi again, tried changing the S3V_UDELAY when i first got the lockup, but that made no difference. Ok, so we keep 1. how much is logged differs everytime i try even with the udelay in the debug macro, i've attached a log where it gets a bit further than the '!s3v_dma_is_ready: -BAD-'. So i guess it hangs at a different time every try. Do you know if Virge DX supported 64K DMA buffers? - I know: I am the one who should know -but- I have just docs for VirgeMX and no more DX ; ( Could you try recompiling drm module and XFree driver defining S3V_BUF_4K? Another point: try commenting out -all- the S3V_WRITE to 0x850C. I am not sure if that is MX specific and it was not in Utah code (did you ever try? Did it use to work for you?). If this is still failing, try setting #if 0 in s3v_dma.c, line 57 [it is the hw reset code - is is been called from my libGL too]. Then delete the comment to reactivate S3V_WRITE(S3V_CMD_DMA_ENABLE_REG, 0x1); at line 270 of s3v_dma.c. (It was in the Utah approach but I found it useless in my driver) seems it never gets to where it prints out the *** buf completed after %i...(in your solution b), atleast its never in the log, and it still hangs. You did comment out s3v_do_reset(dev); after if (times40), didn't you? mmm... could you add a s3v_do_status(dev); in void s3v_dma_check(void* _dev), immediately after static u16 times=0; Now, look at the logs: is s3v_do_status being called? If not, it is a kernel issue with enqueing to the timer queue (could you try a 2.4.18 kernel?). If yes it is a dma issue and I will try to work it out. From the new log tell me if s3v_do_status is showing progress: is rp getting nearer to wp? do you know if anyone else has gotten it to work for them yet? Me ; ) I got it on the VirgeGX box of a friend of mine, when it was in earlier stage of development (January). The point is that DMA structure ain't changed from my first snapshots in November (of course I changed the way kernel handle it to gain a 40% speed boost), but DMA regs handling did not change so much. And 2 people at that time reported it worked: you were one of them... ... do you still have this old code? Does it still run on your box? Could you send me the old drm version (I am not sure I have it any longer here), so that I will check if something went wrong? Good luck! Vale, - max P.S: how could there be a [drm:s3v_dma_dispatch] done dispatch in the log? I have no such printk! Did you add it? : ) In which point of the code is it? Could you add a s3v_do_status(dev); at the end of s3v_dma_dispatch, before the up(s3v_buf_sem); It should log something like rp=0x0 and wp=0xyz. Can you confirm me this? ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mach64-0-0-3-branch multitexture fix
On 2002.03.19 23:42 Sergey V. Udaltsov wrote: some other test suites on the new branch as well. This would be a good time for testers to do a fresh checkout and look for bugs. When the trunk As a tester, I'd like to try. Now, when Jose is on holidays, where could I get those wonderful 1.5M builds? Jose's directory contains the files 3 days old:( I dont' know what happened for sure there. The tree wasn't being built. I ran my script in parts but everything worked well in the end, and I didn't come to the conclusion of what was the problem. There is a recent snapshot now. Now I'll just wait for the next cron job to see if everything is really working fine. Note: Please contact me whenever the snapshots aren't being built because I didn't setup any notification mechanism yet and I don't use those snapshots since I always have an updated CVS tree on my box. What's the end of the story with the sourceforge farm? After I requested an increase in my quota to the CF team they promptly agreed to double it. I'm working on adapting the scripts as I write this email. Initially the snapshots will be on http://dri.sourceforge.net/snapshots/cf/ . Once everything is running fine I'll discontinue the snapshots in my workstation and have the cf making them instead. So I think we can try to focus on the DMA work now. Frank, can you check Hurray! Faster and faster! And I almost see the AGP mapping working on the horizon!:) Keep up your great work, Sergey José Fonseca ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: CVS Access, was: Re: [Dri-devel] S3 Virge DRI completed (almost)
max wrote: On Tuesday 19 March 2002 15:58, Keith Whitwell wrote: OK. Done. Let me know if you need help creating a branch for this. Make sure you read the CVS Policies document in the developer documentation section of dri.sf.net -- if in doubt, ask... Keith mmm... I read through the CVS Policies doc, but being no CVS guru I am a bit confused. For the first time, I'd prefer you could suggest me the right cvs syntax to upload my branch. Just send me the list of CVS commands I will have to digit from my 'xc' dir. When I will commit Savage4 code, I will know something more on CVS so I will do it on my own. Promised. For the moment being, thanks in advance, I'd say something like: tag the repostiory cvs rtag -b s3v-0-0-1-branch xc checkout the branch cvs checkout -r s3v-0-0-1-branch xc get everything working in the checked out tree add new directories files cvs add ... when you're really sure cvs commit ... Keith ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mach64-0-0-3-branch multitexture fix
On 2002.03.20 16:19 Leif Delgass wrote: ... It looks like there is a new package in the bleeding-edge directory that was built today that you could try. I'm not sure if Jose was able to setup the build on sourceforge or if these are being uploaded from his site. It still from my site. I figured the problem that was preventing to accomplish the previous builds of the mach64 snapshots: the cron jobs PATH variable didn't found the lndir program since it's not in /bin:/usr/sbin but in /usr/X11R6/bin/lndir. The compiler farm is on hold because although there is no quota limit I ran into lack of free hd space... ... -- Leif Delgass http://www.retinalburn.net Regards, José Fonseca ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] S3 Virge DRI completed (almost)
If this is still failing, try setting #if 0 in s3v_dma.c, line 57 [it is the hw reset code - is is been called from my libGL too]. Then delete the comment to reactivate S3V_WRITE(S3V_CMD_DMA_ENABLE_REG, 0x1); at line 270 of s3v_dma.c. (It was in the Utah approach but I found it useless in my driver) that fixed it for me, thanks! P.S: how could there be a [drm:s3v_dma_dispatch] done dispatch in oops, just something left from my first troubleshooting =) ahhh, now i can finally sit back and enjoy hw-accelerated gears on my virge. i get around 75fps on my pentium 200mhz thanks again max! /anders -- ___ Sign-up for your own FREE Personalized E-mail at Mail.com http://www.mail.com/?sr=signup Win the Ultimate Hawaiian Experience from Travelocity. http://ad.doubleclick.net/clk;4018363;6991039;n?http://svc.travelocity.com/promos/winhawaii/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] S3 Virge DRI completed (almost)
On Wednesday 20 March 2002 18:29, Anders Haugen wrote: If this is still failing, try setting #if 0 in s3v_dma.c, line 57 [it is the hw reset code - is is been called from my libGL too]. Then delete the comment to reactivate S3V_WRITE(S3V_CMD_DMA_ENABLE_REG, 0x1); at line 270 of s3v_dma.c. (It was in the Utah approach but I found it useless in my driver) that fixed it for me, thanks! *** to Anders *** Uhm, (that = #if 0 in s3v_dma.c) or (that = S3V_WRITE(S3V_CMD_DMA_ENABLE_REG, 0x1)? Did you need both changes to fix the lockup? P.S: how could there be a [drm:s3v_dma_dispatch] done dispatch in oops, just something left from my first troubleshooting =) No problemo. Could you please try to back out all the changes (maybe you just did, just to know...), but the one which fixed the problem? So we can be sure it is that which hurts. ahhh, now i can finally sit back and enjoy hw-accelerated gears on my virge. i get around 75fps on my pentium 200mhz BTW: did you turn debug off? both drm general and s3v specififc? I thought you should get around ~100 fps with gears on a DX and pentium 200. I get ~135 fps on a VirgeMX with a PII 233. You should not run much slower. Let me know (however the greatest speed-up you will notice in 3d games [ever tried battalion?] and texture apps [try newave or underwater]. They are in SuSE glutdemos - which distro are you running?). thanks again max! Nothing, my due. *** to DRI Virge people *** Did anyone else with a VirgeDX had the same problem of Anders with my code? If so I will add an #ifdef for Virges DX to enable the change. Regards, vale, - max ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] S3 Virge DRI completed (almost)
Uhm, (that = #if 0 in s3v_dma.c) or (that = S3V_WRITE(S3V_CMD_DMA_ENABLE_REG, 0x1)? Did you need both changes to fix the lockup? ok, i see - thougth you meant i had to do both, tested again now and only the last one is needed (the S3V_WRITE_CMD_DMA_ENABLE_REG, 0x1) just to be sure i also deleted the drm/kernel folder and extracted the files from your tarball again, and then just uncommented the S3V_WRITE_CMD_DMA_ENABLE_REG line. i didn't make any changes to the other files. BTW: did you turn debug off? both drm general and s3v specififc? now i get 84-85 fps, guess i had forgotten to disable the drm debug. thats about 2.5/3 times as fast as software mode is for me. underwater]. They are in SuSE glutdemos - which distro are you running?). the computer im testing this on has redhat 7.1 i haven't got the glutdemos, so i'll download them too and see how they work. /anders -- ___ Sign-up for your own FREE Personalized E-mail at Mail.com http://www.mail.com/?sr=signup Win the Ultimate Hawaiian Experience from Travelocity. http://ad.doubleclick.net/clk;4018363;6991039;n?http://svc.travelocity.com/promos/winhawaii/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] glSamplePass missing in libGL.so (only glSamplePassARB available)
Andreas Stenglein wrote: Hello! just discoverd that (in my) libGL.so theres no glSamplePass symbol available. its build from today (2002-03-20) DRI-trunk-code. And its not available in the tcl-0-0-branch, too. strings libGL.so | grep glSamplePass glSamplePassARB glSamplePassARB should not exist. There was some confusion when the spec was initially released (it exists in the older SGI version of the extension). -Brian ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Radeon AGP?
There was some talk awhile back about adding support for AGP texturing in the Radeon driver. Whatever happened with that? -- Tell that to the Marines! ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon AGP?
On Wed, Mar 20, 2002 at 12:26:41PM -0800, Ian Romanick wrote: There was some talk awhile back about adding support for AGP texturing in the Radeon driver. Whatever happened with that? I've actually got an implementation of AGP texturing for the Radeon that seems to work. I've also got Michael's 3 TMU patch rolled into my tree. I haven't released any of this yet. Right now the policy for texture management is really simplistic. It tries card memory, then AGP, and finally kicks things off the card. That's really not optimal and I wouldn't recommend it being enabled for general use until something smarter is in place. I suppose I could check this in somewhere since I think it all works. New branch or onto tcl? It's currently based off the trunk. - |Daryll ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] glSamplePass
Hello! so maybe shouldnt it be deleted from gl.h? best regards, Andreas [EMAIL PROTECTED] ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] glSamplePass
On Wed, Mar 20, 2002 at 10:17:26PM +0100, Andreas Stenglein wrote: so maybe shouldnt it be deleted from gl.h? If I understand Brian correctly, gl.h (which has glSamplePass) is correct, but the library (which has glSamplePassARB) is not correct. -- Tell that to the Marines! ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] glSamplePass
Ian Romanick wrote: On Wed, Mar 20, 2002 at 10:17:26PM +0100, Andreas Stenglein wrote: so maybe shouldnt it be deleted from gl.h? If I understand Brian correctly, gl.h (which has glSamplePass) is correct, but the library (which has glSamplePassARB) is not correct. No, glSamplePass() and glSamplePassARB() don't (or shouldn't) exist. I guess I missed the occurance of it in gl.h - I'll remove it for Mesa 4.0.2. A preliminary version of the GL_ARB_multisample spec had the entry point, but it eventually got dropped. Unfortunately, a version of the spec with the entrypoint was floating around for a while. That was the version of the spec that I was reading when I added the new functions to Mesa last summer. -Brian ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon AGP?
Daryll Strauss wrote: On Wed, Mar 20, 2002 at 12:26:41PM -0800, Ian Romanick wrote: There was some talk awhile back about adding support for AGP texturing in the Radeon driver. Whatever happened with that? I've actually got an implementation of AGP texturing for the Radeon that seems to work. I've also got Michael's 3 TMU patch rolled into my tree. I haven't released any of this yet. Right now the policy for texture management is really simplistic. It tries card memory, then AGP, and finally kicks things off the card. That's really not optimal and I wouldn't recommend it being enabled for general use until something smarter is in place. I suppose I could check this in somewhere since I think it all works. New branch or onto tcl? It's currently based off the trunk. Michael also implemented agp support for radeon with a similar simplistic strategy, but ran into some issues looking at tcl and/or mesa-4-0. I think these turned out to be artefacts rather than anything serious. In any case I think he decided to wait on some forthcoming reorganization of the texture management code in all the drivers... (nudge nudge, wink wink) Anyway, it sounds like this has now been done twice: maybe someone should commit something... Keith ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon AGP?
On Wed, Mar 20, 2002 at 09:44:22PM +, Keith Whitwell wrote: Daryll Strauss wrote: On Wed, Mar 20, 2002 at 12:26:41PM -0800, Ian Romanick wrote: There was some talk awhile back about adding support for AGP texturing in the Radeon driver. Whatever happened with that? I've actually got an implementation of AGP texturing for the Radeon that seems to work. I've also got Michael's 3 TMU patch rolled into my tree. I haven't released any of this yet. Right now the policy for texture management is really simplistic. It tries card memory, then AGP, and finally kicks things off the card. That's really not optimal and I wouldn't recommend it being enabled for general use until something smarter is in place. I suppose I could check this in somewhere since I think it all works. New branch or onto tcl? It's currently based off the trunk. Michael also implemented agp support for radeon with a similar simplistic strategy, but ran into some issues looking at tcl and/or mesa-4-0. I think these turned out to be artefacts rather than anything serious. In any case I think he decided to wait on some forthcoming reorganization of the texture management code in all the drivers... (nudge nudge, wink wink) Heh...which is actually why I was asking. :) There are a number of code paths in my code that I can't test on the Radeon (one of my two development platforms) without AGP texturing. Anyway, it sounds like this has now been done twice: maybe someone should commit something... That would be nice. Hopefully we'll be able to worry about making it good soon. Hopefully... -- Tell that to the Marines! ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon AGP?
On Wed, Mar 20, 2002 at 09:44:22PM +, Keith Whitwell wrote: Michael also implemented agp support for radeon with a similar simplistic strategy, but ran into some issues looking at tcl and/or mesa-4-0. I think these turned out to be artefacts rather than anything serious. In any case I think he decided to wait on some forthcoming reorganization of the texture management code in all the drivers... (nudge nudge, wink wink) Anyway, it sounds like this has now been done twice: maybe someone should commit something... Since I started with Michael's patch, I don't think we overlapped much. I just fixed a few things along the way. I do agree it should get checked in somewhere. - |Daryll ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon AGP?
On Wed, Mar 20, 2002 at 01:51:06PM -0800, Ian Romanick wrote: Michael also implemented agp support for radeon with a similar simplistic strategy, but ran into some issues looking at tcl and/or mesa-4-0. I think these turned out to be artefacts rather than anything serious. In any case I think he decided to wait on some forthcoming reorganization of the texture management code in all the drivers... (nudge nudge, wink wink) Heh...which is actually why I was asking. :) There are a number of code paths in my code that I can't test on the Radeon (one of my two development platforms) without AGP texturing. That's confusing, since 'AGP' is really already there, it's not enabled as such, you just allocate from the RADEON_AGP_HEAP instead of the RADEON_CARD_HEAP. (Confusing because if your code replaces the mm in the radeon driver, you'll be writing the code you're asking to be committed?) The fix for current code (in all trunks afaiaa) is that RADEON_AGP_TEX_OFFSET is 0x0200 and it should be 0x0400 (at least on my radeon - I don't know what that does to 64mb radeons, 7500's, mobilities etc? - the 0x0200 figure is left over from the r128 by the looks of it, so perhaps it is a constant?) Beyond that, there's no magic that I found that needs to be done, so you can ignore the 'fixup agp texture offset' that's in the #if 0 part of radeon_texmem, you just add the mmAlloc offset to the heap offset in the same way card local textures are done. The patch is in the archives of this list so you could grab that (next to nothing has changed in this area in TCL) I can probably dig it up if you can't find it. That said, I've been implementing utah-glx swapping c/w AGP texturing in a way that only the overrun goes into AGP even as these messages arrived. It sounds like you are doing much the same...which is a waste of one of our efforts - are you saying that IBM are letting you release your code now? If they have, perhaps I should jump to another item on my list? Lastly, it may well crash a load of machines (although the driver uses agp anyway, I bet there are dodgy motherboards out there that don't like it and a couple of people said their machines had crashed with my patch, unless the fixes Daryll mentioned fix this?) so it may need to be an env variable or XF86Config-4 option? -- Michael. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] S3 Virge DRI completed (almost)
On Wednesday 20 March 2002 19:42, Anders Haugen wrote: ok, i see - thougth you meant i had to do both, tested again now and only the last one is needed (the S3V_WRITE_CMD_DMA_ENABLE_REG, 0x1) Wonderful, thank for your persistence it was very helpful. I will had an #ifdef _VIRGEDX in my code so that it will worl out of the box next time ; ) And this will be the version I will commit to cvs tomorrow. just to be sure i also deleted the drm/kernel folder and extracted the files from your tarball again, and then just uncommented the S3V_WRITE_CMD_DMA_ENABLE_REG line. i didn't make any changes to the other files. ; ) I like your style. now i get 84-85 fps, guess i had forgotten to disable the drm debug. thats about 2.5/3 times as fast as software mode is for me. We are getting close. I thought it should run around ~90/100 on a machine like yours. Could you try: - turning gears to the slim side (so that you will just see the thin profile). How much you scored? - reduce window, enlarge window. Does speed change much? (we are bitblitting [so win size is quite relevant] not page flipping: in fullscreen mode -if we will ever implement it- speed will be greater) - overclock your cpu [try with jumpers to run it at 233] it should not be too hard (try then to recompile your kernel to see everything is OK) - how fast is your RAM? Could you give me result from hdparm -T -t /dev/hda the computer im testing this on has redhat 7.1 i haven't got the glutdemos, so i'll download them too and see how they work. Ok. BTW: What wm are you running? If you have less then 128 (64, isnt'it?) please don't run gmome/kde concurrently to opengl apps but a light wm (try wmaker or xfce), otherwise I noticed slow down due to low memory condition. Sometimes X hung at the start since memory got fragmented and it was not even able to allocate the DMA buffers ; ( So I resorted to lighter WMs, and lowered DMA buffers (64k) from 32 to 16. Vale, - max ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] savage crew (new entry)
On Thursday 21 March 2002 00:54, Jerome Roussel wrote: Hello, Bonjour mon ami. I am intersted like a lot of people in writing a DRI for S3 Savage So join the Savage crew. (in my case the mx one at least) but I don't know the spec of the chip. You are lucky. The MX (like Savage3D) was already supported in Utah. So everything you need to know is already documented in savage Utah driver (see utah-glx.sf.net). I do not know how you work for the virge but I have read that it is very hard to get the Spec from S3graphic. Yep. You will have to be very patient. Like everything else in life it will take its time. Are you sure you want to code? It is a painful (though exciting) path to get a 3d driver working under linux... Could you give some advice please? Ok. (I suppose you can code C). That is what I did [devoting around 1 hour a day to this task, for the last 5 months]: a) read Linux Device Drivers 2nd edition (one of the authors, Alessandro, is italian like me and a nice chap too, so this is a must). It will help you very much to refine your kernel knowledge and to code a fast and stable drm kernel module. b) study DRI code: start with drm and try to get a working kernel module. Next analyze the XFree drivers that support DRI (like r128 or mga) and try to understand what you need to add to patch your X driver and make it DRI aware. c) study a couple of Mesa/DRI driver (I studied i810 and gamma) to understand how Mesa calling are converted in driver specific regs command. d) don'f forget to read all the docs around DRI site. e) if everything fails, I will be here to help and share my knowledge. [BTW: I even started a doc (step by step intro to code a DRM/DRI driver), but it is still too cahotic to be helpful] Could you explain me how you manage to build you driver alone??? You got to be clever, determined, patient and willy to spend at least 1 hour a day for some times (if you are a good coder nut work all alone and can just spend ~1 hour per day on this project, it could take you [including studing time] up to 6 months) And with which material??? VirgeMX docs (since I tend to be a smart chap they sent it to me in a couple of days, but this was a lucky case). Rubini's book. DRI code. Vale, - max ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon AGP?
On Wed, Mar 20, 2002 at 09:44:22PM +, Keith Whitwell wrote: Michael also implemented agp support for radeon with a similar simplistic strategy, but ran into some issues looking at tcl and/or mesa-4-0. I think these turned out to be artefacts rather than anything serious. In any case I think he decided to wait on some forthcoming reorganization of the texture management code in all the drivers... (nudge nudge, wink wink) Currently I'm doing this a) Add textures to card local unless 'useagp' is true (and user wants agp texturing - not implemented this yet) b) If we need to swap out textures i) If there are old texture(s) that weren't used on the last frame swap them (i.e current LRU) ii) Otherwise, set the useagp flag, swap textures from the front of the list (utah-glx + agp, if you do use agp, you don't actually swap) c) At swapbuffer time, reset useagp flag if texture bytes used this frame texture bytes used previous frame. d) At BindTexture , if the texture is resident in agp and the sum of it's size and the texture space we used on the last frame the amount of card local mem we've got and useagp is false, swap it out of agp (i.e try to detect when we no longer need agp textures for overflow and get them put back in local card) It seems to work quite well with limited testing so far. In RTCW, high textures, quite a few places on the maps drop to 5 or 6 fps. This gets closer to the frame rates that using normal textures gets (not using agp and some of those 5fps get to ~20fps, a win, but it's still swapping a lot of textures). AGP seems a big win over swapping from either end of the list (although it might be possible to improve the uploading so the MRU case is better?) I'm fine tuning things at the moment (It seems too aggressive at swapping textures back in from agp) Comments welcome on the approach. Anyway, it sounds like this has now been done twice: maybe someone should commit something... I'll post some code tomorrow, just need to tidy it up and make the agp-local mem a bit smoother. -- Michael. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
