Menu
▾
▴
utah-glx-dev
|
From: Philip B. <ph...@bo...> - 2003-08-06 23:35:24
|
On Wed, Aug 06, 2003 at 11:13:57PM +0000, Dean McEwan wrote:
> Tux racer doesn't load so I don't think its working,
bad, bad test.
tux racer will not load against utah-glx, due to its extended requirements,
and poor programming on their side.
(they should do fallbacks when OpenGL extensions arent available.
they dont)
[ The new tree I'm working on, should eventually be able to support
tuxracer]
You need a simpler test program.
The standard "is OpenGL working?" program, is glxgears.
First, you should check with glxinfo, to see that the "right" version of
GLX is loaded, and that your libGL is the utah-glx one.
The output should look something like
name of display: :0.0
@@Created GLX Context..
display: :0 screen: 0
direct rendering: No
server glx vendor string: XFree86 GLX protocol written by Steven G. Parker
server glx version string: 1.2 GLX 0.9
server glx extensions:
, GLX_None
client glx vendor string: Brian Paul
client glx version string: 1.2 Mesa 3.0
client glx extensions:
GLX_utah_direct_0_2, GLX_no_accel
GLX extensions:
, GLX_None
OpenGL vendor string: Brian Paul
OpenGL renderer string: Mesa X11
OpenGL version string: 1.2 Mesa 3.2.1
OpenGL extensions:
glu version: 1.3
glu extensions:
GLU_EXT_nurbs_tessellator, GLU_EXT_object_space_tess
If the output looks different, then double-check
/var/log/XFree86.0.log
to see that the Utah-GLX module was loaded, not some other one.
In particular, if you see significantly more GLX extensions, then
you know you arent using utah-glx :-/
Unfortunatley, I'm not at my dev box right now, so cant give you a magic
string to look for. but if you "grep -i utah", there should probably be
SOMETHING in XFree86.0.log ;->
If it IS present in /var/log/XFree86.0.log, but glxinfo doesnt give you the
expected output, then you need to relink a copy of glxinfo against the
libGL.so that comes with utah-glx
(or just run glxinfo with LD_LIBRARY_PATH set appropriately)
Once THAT is happy, then move on to trying glxgears.
Note: I'm Cc'ing the mailing list on this one, for posterity. But
you can keep emailing me directly for any extra fiddly bits.
|
|
From: Dean M. <dea...@eu...> - 2003-08-09 04:15:43
|
>Hmm. actually, it appears that it does have an install target. >intersting. but it doesn't set the modes. >So, you could do a make install in tehre, see whre it goes, and then check >the perms. > > > >but its more likely the DMA issue > It seems it doesn't work in ROOT now either, I thought the patch I put in there (servGL) for mach DMA that was supposed to resize the FIFO buffers would work. Sheesh. The idea (someone elses, may I note) was to resize the fifo buffers so that they didn't interfere with DMA, under the impression that as it starts off smaller (FIFO) and is artificially enlarged by XF4 stock drivers, and shrinking it again should fix it all. Maybe I should go into the stock drivers and shrink it so it never gets bigger in the first place? Maybe the problem lies somewhere else. Maybe I should bug the person who wrote the X drivers for 4? Or I could hassle a ATI developer into telling us all whats wrong... I like that last one... P.S would you all CC me in replies as my daily digest isn't for 23 hours... Deano. Need a new email address that people can remember Check out the new EudoraMail at http://www.eudoramail.com |
|
From: Philip B. <ph...@bo...> - 2003-08-09 04:46:52
|
On Sat, Aug 09, 2003 at 04:15:29AM +0000, Dean McEwan wrote: > >but its more likely the DMA issue > > > > It seems it doesn't work in ROOT now either, I thought the > patch I put in there (servGL) for mach DMA that was supposed > to resize the FIFO buffers would work. Sheesh. I told you to start with the "known good" snapshot :-) > Maybe I should go into the stock drivers and shrink it so > it never gets bigger in the first place? Start by turning off DMA completely, and get that definately working first. It's still not clear to me that you have that? |
|
From: Frank C. E. <fe...@ai...> - 2003-08-11 00:34:21
|
On Saturday 09 August 2003 12:15 am, Dean McEwan wrote: > It seems it doesn't work in ROOT now either, I thought the > patch I put in there (servGL) for mach DMA that was supposed > to resize the FIFO buffers would work. Sheesh. Hm... I may have missed something- I've not had a chance to revisit things (Been swamped trying to keep a roof over my head- hopefully, I'll get at least a 6 month respite within a week or so...). For the DRI drivers we had to shrink the FIFO buffer setting and reset the chip because while the 2D support didn't have a problem with it, the DMA pathway DID. I'm going to look at what I put up on the list and see if I've missed something in the mix. I might have missed the proper chip reset sequence, in which case, it wouldn't work right anyway. > The idea (someone elses, may I note) was to resize the fifo > buffers so that they didn't interfere with DMA, under the > impression that as it starts off smaller (FIFO) and is artificially > enlarged by XF4 stock drivers, and shrinking it again should fix it all. That would be my idea, based off of experience with the work on getting the DRI support for Mach64 going. We had three developers scratching our collective heads, wondering what might be wrong when it WOULD work if you had a test driver that was loaded up and ran before X loaded and then wouldn't work to save your life after X was loaded. It then occurred to us that there was one thing changed- the FIFO size information in the registers was changed to enlarge the FIFO size (I'm still not sure what possessed ATI to put that in there as a writable register- the FIFO is a piece of hardware ON the chip, not in display or system memory...). After changing it and reseting it on the fly, the whole thing started working for us. > Maybe I should go into the stock drivers and shrink it so > it never gets bigger in the first place? Well, ideally, someone should flip Alan Hourihane a patch to integrate into the ATI drivers- but for now, I'd hold off. We should be trying to figure out why this all doesn't work right. Good apps to test with would be something like a copy of Heretic II (Demo or retail), Quake 3:Arena, or BZ Flag- all of the aforementioned games worked fine with it when I was actively maintaining the G400 and Mach64 drivers. glxgears is also a good first-start test of things. > Maybe the problem lies somewhere else. Could be. There may be several things going on here- have you checked the code in PDMA mode to see if the driver code even works at all? I DO know that if you don't reset the FIFO size you won't see DMA ever- there may be other things going on that's breaking it in other places. > Maybe I should bug the person who wrote the X drivers for 4? Uh, Alan's busy with DRI drivers for other chipsets and such. He might be able to help you, he may not. I, however, am back listening to the list and I should have something of a machine in use shortly to be able to help out with fixing this. > Or I could hassle a ATI developer into telling us all whats > wrong... > > I like that last one... Yeah, I do too- problem is it won't get anywhere and it'll just annoy ATI, something we don't want. They're still selling this chipset- for server machines. It's largely no longer a going concern as far as they're concerned. -- Frank Earl |
|
From: Frank C. E. <fe...@ai...> - 2003-08-11 00:40:00
|
On Saturday 09 August 2003 12:46 am, Philip Brown wrote: > I told you to start with the "known good" snapshot :-) Having said this, what IS a "known good" snapshot? :-> Is the glx-4 source tree usable enough to get things kick-started, or should I be working out of your rsync-ed stuff? > Start by turning off DMA completely, and get that definately working first. > It's still not clear to me that you have that? If it were me, I'd be forcing the driver into the PDMA mode (i.e. You fill DMA-able buffers, but you have the CPU MMIO the buffer's commands instead of ask the GPU to DMA it to itself.). A failure in PDMA indicates a failure in the whole driver code or the server itself. Hopefully, in another couple of days, I can manage to get one of my machines that has a Mach64 in it back into service enough to test things and maybe give you all a helping hand for at least that chipset... -- Frank Earl |
|
From: Philip B. <ph...@bo...> - 2003-08-11 05:43:06
|
On Sun, Aug 10, 2003 at 07:40:36PM -0400, Frank C. Earl wrote: > On Saturday 09 August 2003 12:46 am, Philip Brown wrote: > > > I told you to start with the "known good" snapshot :-) > > Having said this, what IS a "known good" snapshot? :-> The latest tarfile in the download area. See below > Is the glx-4 source tree usable enough to get things kick-started, or should I > be working out of your rsync-ed stuff? my rsync'd stuff definately does NOT fit the definition of "known good" ;-) It's a "experienced developers only, enter at your own risk" thing. People should get experience with the mainline tree first, before messing with that. only software rendering works, and its only a stop-gap proof of concept thing, because people should mostly be looking at approximately how the software bit does things, and then fleshing out the hardware side. There are no working hardware-accel drivers in my rsync tree currently. Which is unfortunately, since it has mesa5, and so should finally be able to support the extra frills we've been missing. The latest cvs in glx-xf4 "should" work. but if there is any doubt whatsoever, a new developer should start with a tarfile, like utah-glx-src-levent-20030220.tar.gz > If it were me, I'd be forcing the driver into the PDMA mode ditto. > Hopefully, in another couple of > days, I can manage to get one of my machines that has a Mach64 in it back > into service enough to test things and maybe give you all a helping hand for > at least that chipset... excellent! I look forward to that mach64 patch a few months ago, being finally verified and put into the mainline cvs tree ;-) |
|
From: Robert L. <bo...@ya...> - 2003-08-11 11:26:31
|
On Monday 11 August 2003 15:43, Philip Brown wrote: > On Sun, Aug 10, 2003 at 07:40:36PM -0400, Frank C. Earl wrote: > > On Saturday 09 August 2003 12:46 am, Philip Brown wrote: > > > I told you to start with the "known good" snapshot :-) > > > > Having said this, what IS a "known good" snapshot? :-> > > The latest tarfile in the download area. See below > > > Is the glx-4 source tree usable enough to get things kick-started, or > > should I be working out of your rsync-ed stuff? > > my rsync'd stuff definately does NOT fit the definition of "known good" ;-) > It's a "experienced developers only, enter at your own risk" thing. > People should get experience with the mainline tree first, before messing > with that. only software rendering works, and its only a stop-gap proof of > concept thing, because people should mostly be looking at approximately how > the software bit does things, and then fleshing out the hardware side. > There are no working hardware-accel drivers in my rsync tree currently. > Which is unfortunately, since it has mesa5, and so should finally be able > to support the extra frills we've been missing. > > > The latest cvs in glx-xf4 "should" work. but if there is any doubt > whatsoever, a new developer should start with a tarfile, like > utah-glx-src-levent-20030220.tar.gz > > > If it were me, I'd be forcing the driver into the PDMA mode > > ditto. > > > Hopefully, in another couple of > > days, I can manage to get one of my machines that has a Mach64 in it back > > into service enough to test things and maybe give you all a helping hand > > for at least that chipset... > > excellent! I look forward to that mach64 patch a few months ago, being > finally verified and put into the mainline cvs tree ;-) > I spent a lot of time trying to get DMA working in the Mach64 driver and was never successful (Read the archives). This includes with or without the FIFO resize mentioned. The problem almost always managed to lock up the graphics engine too. I added full context dumps of the chip registers but could never find a reason for the latchup. A full context restore of the registers to the state they were before the DMA was started and a chipset reset failed to restore functionality. In the end I concluded that the Mach 64 wasn't worth the effort I was putting into it and went on to help with the mga driver instead. Oh and by the way, it does work in PDMA mode, if you hack the code to fail the DMA test then it will fall back to PDMA quite well and works OK Bob |
Thanks for helping keep SourceForge clean.
X