Re: [Dri-devel] 7500 lockup kludge-around
Michael wrote: On Thu, Mar 14, 2002 at 08:29:47AM -0800, Keith Packard wrote: Around 12 o'clock on Mar 14, Keith Whitwell wrote: A slightly less buggy version (still untested). My incoming email seems to be hosed... I haven't locked this up with test involving textures. I still have a reliable lockup when disabling textures in bzflag which is resolved with a clean reboot (no reset button required). I've not managed to reproduce this (unless this is another span function fprintf hang. If so, it probably works with latest cvs) The transparency should be working now? And, GL_LUMINANCE_ALPHA textures are broken as well -- the alpha channel is bilinear interpolated but the luminance channel is interpolated in Y but nearest in X. This is trivially fixed making LUMINANCE_ALPHA textures use RGBA internally (aka how r128 does it) There seems a high correlation between the hw texture formats on the radeon and r128, except what's called RADEON_TXFORMAT_AI88 used for LUMINANCE_ALPHA is a colour index mode on the r128. A stab in the dark, but is this difference definately correct? If AI88 isn't working we should certainly go to RGBA. Keith ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mach64 binaries: do work! Was: do not work...
But now that you touched on the subject, why don't you help on the development as well!? Well, I'd be glad but there are some problems. Unfortunately I am already involved in 2 projects (my own GSwitchIt and SQL/jEdit) so I simply has no time for anything else (well, I do not count my family:). Also, I has no background in 3D development, so the learning curve for me would be too long. I am trying to do my best in testing but I am afraid for foreseeble future it is the only way I can afford. Though, at some point hopefully I'll be happy to join the team. BTW, is there a way to get the wonderful DRI devel FAQ as a single document (in PDF or - better - in HTML format)? I'd like to have it in my Visor but I could not find it:( Cheers, Sergey ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mach64 binaries: do work! Was: do not work...
Jose Fonseca wrote: The latest snapshot, works. I've checked it myself. The problem was libdrm.a which is not as device independent as thought. It has some interface functions which in the case of mach64 are new and not available in the XFree86 4.x releases. This has been a sleeper issue for a while. I'll look into what can be done to improve this. Regards, Jens -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] 7500 lockup kludge-around
Around 8 o'clock on Mar 15, Michael wrote: I've not managed to reproduce this (unless this is another span function fprintf hang. If so, it probably works with latest cvs) Looks like that was it -- current CVS doesn't hang anymore. There seems a high correlation between the hw texture formats on the radeon and r128, except what's called RADEON_TXFORMAT_AI88 used for LUMINANCE_ALPHA is a colour index mode on the r128. A stab in the dark, but is this difference definately correct? Did I mention that the tdfx driver has the same problem? The software driver looks correct. Would a smaller test case help at all? Keith PackardXFree86 Core TeamCompaq Cambridge Research Lab ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Easter vacations compiler farm
In the next 3 weeks I'll be on vacations back in Portugal. I'm afraid that I'll slow down a little since I'll spend most of my time with my friends and family (especially my girlfriend, who would strangle me to death if she caught me playing around with the computer on vacations! :-) This also means that I won't have permanent internet connection, and that I'll answer to emails just on the economic period (which is more or less at the same time that the IRC meetings have been). I'll leave my workstation here at the university running but I just recently knew that there will be some remodeling on our office during my absence, which probably means that the workstation will be down from 25th Mar until my return on 7th Apr... Until then I hope to get the SourceForge compiler farm to make the snapshots instead. I've been reading about how to do that, and it's more or less straightforward. In principle I could just transfer my scripts and crontab it would be done, but unfortunately the SourceForge imposes some quota limits: 512MB hard quota, 256 soft quota. The compiled trunk takes 522 MB on my machine. For start, this means that I can't leave the build trees or even the source trees there - this poses no problem because the build tree is always almost completely rebuilt anyway, and the source tree should be really fast to get from CVS since it's in SourceForge CVS servers as well. Spite of that, I don't have space for a single build. One way to overcome this problem is to remove the '-g' debug info compiler option by applying systematically a patch to the source tree. This will surely reduce significantly the size of the build tree, and if we don't include '-s' strip linker option, we should still get a meaningful backtrace due to the COFF source line information, isn't it? Does anybody have any alternative idea? Regards, José Fonseca ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: tcl-0-0-branch)
Michael Fitzpatrick wrote: CVSROOT:/cvsroot/dri Module name:xc Repository: xc/xc/extras/Mesa/src/ Changes by: leahcim@usw-pr-cvs1.02/03/15 09:49:26 Log message: Fix typo in CONVERT_TEXEL_DWORD for convert_abgr_to_ai88 textures. (fixes text display problem in bzflag) I'll fix this in the Mesa tree too. -Brian ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: Downloadable Radeon Driver and libGL compatability
Jens Owen wrote: Brian Paul wrote: Jens Owen wrote: Brian Paul wrote: Jens Owen wrote: Wasn't this stuff recently submitted to the DRI trunk? Maybe we can fix this incompatability if this hasn't propogated out to any major distros, yet. Yes, we should really fix it ASAP. Was this part of Mesa 4? So this wouldn't have gone out in XFree86 4.2 or any other source releases where we care about binary compatability, right? It's not a Mesa issue, it's an XFree86 libGL issue. Just remove the field from the struct and replace any occuraces of the field with 'currentDrawable. instead. That'll work fine. I've patched every occurance with the attached patch, but 3 out of 5 occurances are from the /extras/Mesa tree. Please propegate this patch back to Mesa, or if you want a different fix, propogate that patch to me so we can sync up the /extra/Mesa tree. I should have been more clear when I wrote it's not a Mesa issue, it's an XFree86 libGL issue. You don't have to change any Mesa code. Mesa's fakeglx.c, glxapi.c and glxapi.h are only used in XFree86 when the GlxBuiltInXMesa option is defined, and when it is, the references to currentReadable are skipped because of the GLX_BUILT_IN_XMESA cpp token being defined. Without doubt, this is somewhat confusing code. Stand-alone Mesa and XFree86's libGL have a lot of overlap and it's sometimes hard to see how the pieces interact. I'm about to check in some changes to both the DRI and Mesa trees to finish this up. Just doing some build testing now. -Brian ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Mesa/GLX updates on trunk
I think I've finally wrapped up some Mesa and GLX issues that have been floating around for a while. For whoever's interested, here's the story: 1. Last summer I started to implement some new GLX features in the mesa-35 branch. One thing I did was to add a 'currentReadable' field to the __GLXContextRec structure. I didn't realize this would break libGL/DRI driver compatibility at the time. But it probably would have been caught when we got close to merging this into the DRI trunk. 2. A few months ago, the mesa-35 branch was reincarnated as the mesa-40 branch and this change got brought over. Around that time, Keith found the compatibility problem. I suggested a repair, but it seemed to get lost. Jens picked up the problem more recently and fixed it. 3. However, Jens's patch unnecessarily removed the currentReadable field from the stand-alone/fake-GLX code in Mesa. An understandable thing, considering how complicated this code is. 4. This morning I reconciled all the changes and updated the Mesa CVS code (both the 4_0_branch and trunk) and the DRI trunk code. Now, the code is all sync'd up and seems to work. 5. I haven't updated the tcl branch yet. I will in a bit. I don't know how closely the mach64 branch is tracking the trunk, so these changes may or may not be of interest there. -Brian ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Mesa 4.0.2 info
Just a quick note: I was hoping to have released Mesa 4.0.2 by now but a trickle of bug fixes and other odds ends have delayed it. I think I'm really close to a release now, but I don't know if I'll get to it this weekend. After I've done so, it would be good to update the DRI trunk and tcl branches with the 4.0.2 code. If nobody volunteers to do so I'll eventually get around to it. -Brian ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Mesa3d-dev] Mesa 4.0.2 info
Brian Paul wrote: Just a quick note: I was hoping to have released Mesa 4.0.2 by now but a trickle of bug fixes and other odds ends have delayed it. I think I'm really close to a release now, but I don't know if I'll get to it this weekend. After I've done so, it would be good to update the DRI trunk and tcl branches with the 4.0.2 code. If nobody volunteers to do so I'll eventually get around to it. Oh, one thing I forgot is that a new rev of the GL/glxext.h and GL/glext.h files from SGI has shown up and I want to incorporate them into 4.0.2. Unfortunately, I found a few problems in each file that I'm hoping SGI will soon fix. -Brian ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mesa/GLX updates on trunk
I just discovered that my recent check-ins break the build in the server-side GLX/Mesa code. I'm working on a fix now. -Brian ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] S3 Virge DRI completed (almost)
Max, It's impressive that you have pulled off a (almost) complete DRI driver on your own! On the other hand you should have reported here your efforts earlier so that others eventual interested could give a hand. (Imagine another Max falling apart in tears after reading your email.. ;-) Anyway, although I have no Virge I do have a Savage4. I had plans of eventually (around summer too) starting a branch with just a software only driver since I never have the card with me except on vacations. In the meanwhile I'm convincing my little brother (which is 18, is crazy about 3D graphics cards, and's going to be a CS student next year) to get get out of the dark side (lazy windows games addict) and get keen on Linux and DRI. It wasn't not so hard to convince him, especially when I said that it was not uncommon to get support from vendors which sometimes even supplied some cards to test/develop... - I'm so bad! But after all, I'm just preparing him to the future, Linux that is! ;o). Bottom line: _please_ keep us posted on your advances on Savage4, as I'll do when that time comes. Otherwise, there will be unnecessary work duplication. Regards, José Fonseca PS: If there is anybody else also interested in working on a Savage4 driver sooner, I may also give a hand in what I can, although mach64 is my priority now. On 2002.03.15 22:34 max wrote: Hello world, I have a working and quite complete DRI/DRM s3 virge driver (quite fast, e.g. glxgears will run ~130-175 fps, but with some limitation, e.g. you will have to turn 2d acceleration off). As soon as I have CVS access I will upload my creature to a new branch. In the meanwhile, if you mail me I will send tarballs so that you can build it by yourself. New CVS will host -later this summer/fall- the Savage4 version too, which I plan to start developing by the end of the year. Here attached you will find the README that will come with the tarball. Vale, yours, - max lingua ([EMAIL PROTECTED]) ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] 7500 lockup kludge-around
Now that my desktop 7500 is working smoothly, my laptop Mobility M6 LY is wedging when the X server trys to synchronize with the engine. It's easy to reproduce without using any GL applications: # XFree86 # X=$! # chvt 1 # chvt 7 # kill $X This same sequence wedges this chip with the XFree86 4.2 radeon DRM. Disable DRI and things are fine. I enabled plenty of debugging in the radeon DRM. When switching to the console and back to X, I see: [drm:radeon_ioctl] pid=1406, cmd=0x4008642a, nr=0x2a, dev 0xe200, auth=1 [drm:radeon_lock] 1 (pid 1406) requests lock (0x0001), flags = 0x000a [drm:radeon_lock] 1 has lock [drm:radeon_ioctl] pid=1406, cmd=0x6444, nr=0x44, dev 0xe200, auth=1 [drm:radeon_cp_idle] radeon_cp_idle [drm:radeon_do_cp_idle] radeon_do_cp_idle [drm:radeon_ioctl] pid=1406, cmd=0x40086442, nr=0x42, dev 0xe200, auth=1 [drm:radeon_cp_stop] radeon_cp_stop [drm:radeon_do_cp_flush] radeon_do_cp_flush [drm:radeon_do_cp_idle] radeon_do_cp_idle [drm:radeon_do_cp_stop] radeon_do_cp_stop [drm:radeon_do_engine_reset] radeon_do_engine_reset [drm:radeon_do_cp_reset] radeon_do_cp_reset [drm:radeon_ioctl] pid=1406, cmd=0x6441, nr=0x41, dev 0xe200, auth=1 [drm:radeon_cp_start] radeon_cp_start [drm:radeon_do_cp_start] radeon_do_cp_start [drm:radeon_ioctl] pid=1406, cmd=0x4008642a, nr=0x2a, dev 0xe200, auth=1 [drm:radeon_lock] 1 (pid 1406) requests lock (0x0001), flags = 0x000a [drm:radeon_lock] 1 has lock [drm:radeon_ioctl] pid=1406, cmd=0x6444, nr=0x44, dev 0xe200, auth=1 [drm:radeon_cp_idle] radeon_cp_idle [drm:radeon_do_cp_idle] radeon_do_cp_idle [drm:radeon_ioctl] pid=1406, cmd=0xc0286429, nr=0x29, dev 0xe200, auth=1 [drm:radeon_freelist_get] skipping buf=0 pid=1406 [drm:radeon_freelist_get] ret buf=1 last=0 pid=0 (and then lots of radeon_cp_indirect calls as the root is repainted) When the X server tries to shut down, I get: [drm:radeon_cp_stop] radeon_cp_stop [drm:radeon_do_cp_flush] radeon_do_cp_flush [drm:radeon_do_cp_idle] radeon_do_cp_idle [drm:radeon_do_wait_for_idle] *ERROR* failed! radeon_status: RBBM_STATUS = 0x80010140 CP_RB_RTPR = 0x0030 CP_RB_WTPR = 0x0055 AIC_CNTL = 0x0002 AIC_STAT = 0x0004 AIC_PT_BASE = 0x TLB_ADDR = 0x TLB_DATA = 0x At this point, the server loops and I see the same sequence over and over until I kill the X server. Further attempts to start the server fail in the same loop until the machine is rebooted. A similar failure mode is: # XFree86 # X=$! # glxgears -display :0 # kill $! This hangs the machine immediately, I do get one diagnostic out of the X server: (EE) RADEON(0): RADEONDRICloseScreen: CP stop -1022 But, the kernel diagnostics don't get written before the machine locks. The number -1022 is supposed to be an errno from drmRadeonStopCP but I can't see how it would get this value. Keith PackardXFree86 Core TeamCompaq Cambridge Research Lab ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] S3 Virge DRI completed (almost)
On Saturday 16 March 2002 00:37, you wrote: Max, It's impressive that you have pulled off a (almost) complete DRI driver on your own! It is even more impressive if you think that I only studied philosophy and laws, and never took a class in CS... ...now that the game is (nearly) over I can admit: it was not easy. Anyway, although I have no Virge I do have a Savage4. Big problem with Savage4 is weird documentation: some docs around the world are missing the 3d part --- mine luckily not, but it is still missing some infos, e.g. it just states that BCI index for z coord of vertex 0 is 0x2h, but doesn't tell me anything about the vertex structure. Should I suppose it is the same it was in Savage3D? Sure like hell BCI indices before the fog tables are quite different ; ( Even worst: the register specs explain nowhere how to choose between different 3d primitives [are quad supported? and in which flavours?]: what I am supposed to do? to guess? For the time being I will go back studying laws, after my July exams I will then come back to code (in the meanwhile I will plan the structure of the Savage4 driver, and refine my knowledge of DRI/DRM and kernel skills). meanwhile I'm convincing my little brother (which is 18, is crazy about 3D I have got a younger bro too [actually very young, just 11], his contribution for the moment is limited to lending me psx games so that I can test my 3d drivers with them. He enjoys Linux more than windows (he didn't even want me to install the latter on his machine), so he has got good taste ; ) Vale, - max ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mesa/GLX updates on trunk
Brian Paul wrote: 5. I haven't updated the tcl branch yet. I will in a bit. I don't know how closely the mach64 branch is tracking the trunk, so these changes may or may not be of interest there. Brian, Thanks for cleaning this up. I don't know about the mach64 branch, but I did make changes to the latest BSD branch in my effort. Regards, Jens -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] ROOTS 2002 USA OLYMPIC BERET qqn
ROOTS 2002 USA OLYMPIC BERET- the hottest fashion trend around right now! http://www.perfectcollectibles.com/index.cfm?action=promopc=awe1 The hottest new fashion trend... only $24.95 ** LIMITED AVAILABILTY** -- This is the 2002 Salt Lake City Official Olympic Team USA Beret. This is the beret that you've seen all the U.S. athletes wearing at the opening, closing and medal ceremonies. ** http://www.perfectcollectibles.com/index.cfm?action=promopc=awe1 Rermove mailto:[EMAIL PROTECTED] xmfprsglgaqqdmiitojbhtriuwvuvuisexlytp ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] S3 Virge DRI completed (almost)
On 2002.03.16 01:53 max wrote: On Saturday 16 March 2002 00:37, you wrote: Max, It's impressive that you have pulled off a (almost) complete DRI driver on your own! It is even more impressive if you think that I only studied philosophy and laws, and never took a class in CS... ...now that the game is (nearly) over I can admit: it was not easy. Anyway, although I have no Virge I do have a Savage4. Big problem with Savage4 is weird documentation: some docs around the world are missing the 3d part --- mine luckily not, but it is still missing some infos, e.g. it just states that BCI index for z coord of vertex 0 is 0x2h, but doesn't tell me anything about the vertex structure. Should I suppose it is the same it was in Savage3D? Sure like hell BCI indices before the fog tables are quite different ; ( Even worst: the register specs explain nowhere how to choose between different 3d primitives [are quad supported? and in which flavours?]: what I am supposed to do? to guess? I have no information at all about the Savage chips. Are they freely available? Anyway, the utah-glx project supports it so it should be a valuable resource in that matter. For the time being I will go back studying laws, after my July exams I will then come back to code (in the meanwhile I will plan the structure of the Savage4 driver, and refine my knowledge of DRI/DRM and kernel skills). meanwhile I'm convincing my little brother (which is 18, is crazy about 3D I have got a younger bro too [actually very young, just 11], his contribution for the moment is limited to lending me psx games so that I can test my 3d drivers with them. He enjoys Linux more than windows (he didn't even want me to install the latter on his machine), so he has got good taste ; ) Could you tell me what psx emulator are you using under linux? I'm curious about it... Vale, - max Regards, José Fonseca ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
