[Dri-devel] Mach64: mach64-0-0-2-branch created and updated
Well. I had to make a pair of commits because I forget to 'add' the new files for the mach64 support before making the first 'commit'. I hope I didn't forget anything. If you find any problem compiling the new branch, please make me know. Best regards. -- M. Teira ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64: mach64-0-0-2-branch created and updated
Manuel Teira wrote: > If you find any problem compiling the new branch, please make me know. OK, let me see. With regards to that libXau problem: it 's sufficient to just copy /usr/X11R6/lib to /usr/X11R6-DRI/lib, the rest of the tree isn't necessary. Otherwise, I followed the DRI compilation guide under "Documentation". The build (or rather, the make install) failed until I removed tdfx from line 821 in file X11R6-DRI/build/xc/lib/GL/mesa/src/drv/Makefile. The instructions for making the nls stuff seem to be outdated, since there no longer is any xc/nls in CVS. taking /usr/X11R6-DRI/lib into ld.so.conf doesn 't help for libGL and libGLU, since those already should exist from any previous X installation in /usr/lib, and /usr/lib is implicitly given preference over anything form ld.so.conf. I had to move the old ones away and symlink/copy over the new ones. Unfortunately, I have a PCI Mach64; modprobe mach64 failed without a helpful error message since agpgart wasn 't installed into the kernel. After modprobing agpgart, then modprobing mach64 (that last one is probably also handled automagically at X startup), glxinfo showed the valued "Direct Rendering enabled". And it was; small differences in the display of 3D apps showed that. However, performance was about as slow as software-rendering; at least for gltron, I got about the same average fps as with software mesa. That is probably due to my card not being an AGP variant (also my mainboard does have a - currently empty - AGP slot). That 's about it - I tested 3D with gears, gltron and blender and all "worked" with a few glitches (not important right now). So, I hope you'll find my report useful. It certainly was fun for me, believe it or not. Thanks for the great work so far, Yours Malte #8-) ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64: mach64-0-0-2-branch created and updated
El Lun 22 Oct 2001 17:52, Malte Cornils escribió: > Manuel Teira wrote: > > If you find any problem compiling the new branch, please make me know. > > OK, let me see. With regards to that libXau problem: it > 's sufficient to just copy /usr/X11R6/lib to /usr/X11R6-DRI/lib, the > rest of the tree isn't necessary. Otherwise, I followed the DRI > compilation guide under "Documentation". O.K. This is just a issue derived from the trimming of the DRI trunk, I hope. > > The build (or rather, the make install) failed until I removed tdfx > from line 821 in file > X11R6-DRI/build/xc/lib/GL/mesa/src/drv/Makefile. Have you got errores related to the glide library? Perhaps you should comment out the line: #define HasGlide3 YES in the host.def file. Or perhaps would be good to comment it out in our mach64 branch. > > The instructions for making the nls stuff seem to be outdated, since > there no longer is any xc/nls in CVS. > > taking /usr/X11R6-DRI/lib into ld.so.conf doesn > 't help for libGL and libGLU, since those already should exist from > any previous X installation in /usr/lib, and /usr/lib is implicitly > given preference over anything form ld.so.conf. I had to move the > old ones away and symlink/copy over the new ones. What I made for the tests was using: export LD_PRELOAD=/usr/X11R6-DRI/lib/libGL.so or export LD_LIBRARY_PATH=/usr/X11R6-DRI/lib > > Unfortunately, I have a PCI Mach64; modprobe mach64 failed without a > helpful error message since agpgart wasn > 't installed into the kernel. After modprobing agpgart, then > modprobing mach64 (that last one is probably also handled > automagically at X startup), glxinfo showed the valued "Direct > Rendering enabled". And it was; small differences in the display of > 3D apps showed that. However, performance was about as slow as > software-rendering; at least for gltron, I got about the same > average fps as with software mesa. > > That is probably due to my card not being an AGP variant (also my > mainboard does have a - currently empty - AGP slot). I don't know. We are not using any AGP feature just now. What processor does your computer have? I'm getting about 215-220 fps in hw mode and no more than 100 (not exactly) in software mode. > > That > 's about it - I tested 3D with gears, gltron and blender and all > "worked" with a few glitches (not important right now). > > So, I hope you'll find my report useful. It certainly was fun for > me, believe it or not. Thank you for your report. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64: mach64-0-0-2-branch created and updated
Manuel Teira wrote: > Have you got errores related to the glide library? > Perhaps you should comment out the line: > #define HasGlide3 YES > in the host.def file. > Or perhaps would be good to comment it out in our mach64 branch. oops. That's likely the problem. I got so used to configure-like scripts to determine what I have installed that I just skipped the Glide stuff in host.def. This might actually help, yes. :-) > What I made for the tests was using: > export LD_PRELOAD=/usr/X11R6-DRI/lib/libGL.so ok, sure that'll work. > > That is probably due to my card not being an AGP variant (also my > > mainboard does have a - currently empty - AGP slot). > > I don't know. We are not using any AGP feature just now. What processor does > your computer have? I'm getting about 215-220 fps in hw mode and no more than > 100 (not exactly) in software mode. ah, this is gears fps now, not gltron, right? ok gears does 160 software now on my Duron 800, while on Mach64-accel it does 260. gltron does 5-15 on mach64, 5-15 on plain mesa, too; although it subjectively seems to be a bit jerkier. Anyway, with the old Utah code I got more (at least 20fps, but on a K6-2 333) but that has time. I'm more concerned about glxgears: in software mode, it shows the three gears moving; in hardware mode, it just shows a huge close-up of the red one moving. Strange, since gltron looks almost equivalent under both modes, with hardware having a bit better texture filtering IMHO. BTW, why does mach64 module insertion fail when agpgart isn't installed if it doesn't use any features from AGP? HTH, Yours Malte #8-) PS: no need to Cc me, I'm on this list. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64: mach64-0-0-2-branch created and updated
Hello, I've done some testing on my machine with the CVS branch that Manuel did so well. I find that it works great on my machine. I get about 27 fps in gltron, but this is a k6 550mhz. Quake 3 was even "nearly" playable in 548x380(or whatever that mode is). I just saw now, that you are using a PCI card. Perhaps I can get this code to my friend with a iMac :-) (anyone know where I can get a PPC cross compilier?) The Mach64 driver calls for agp, which is why it's failing, I suppose that you could take out that call for machines with PCI cards, but AGPgart won't mess up machines even without AGP chipsets. What kind of speed do you get with Pulsar? You might also want to look at the cpu utilization. My frame rate in Pulsar runs from 45-90fps, but the CPU utilization seems to be greater at the slower frame rate. in a window at 1024x768. When I use the -root option it runs about 35fps (again at 1024x768). Though when using the -texture option it's pretty solid at 45fps with cpu at about 50%. Without the -fps option it seems much smoother. By the way, in comparison, my setup doesn't get over 200fps in glxgears, and the cpu is at 100% Malte Cornils wrote: >Manuel Teira wrote: > >>Have you got errores related to the glide library? >>Perhaps you should comment out the line: >>#define HasGlide3 YES >>in the host.def file. >>Or perhaps would be good to comment it out in our mach64 branch. >> > >oops. That's likely the problem. I got so used to configure-like >scripts to determine what I have installed that I just skipped the >Glide stuff in host.def. This might actually help, yes. :-) > >>What I made for the tests was using: >>export LD_PRELOAD=/usr/X11R6-DRI/lib/libGL.so >> > >ok, sure that'll work. > >>>That is probably due to my card not being an AGP variant (also my >>>mainboard does have a - currently empty - AGP slot). >>> >>I don't know. We are not using any AGP feature just now. What processor does >>your computer have? I'm getting about 215-220 fps in hw mode and no more than >>100 (not exactly) in software mode. >> > >ah, this is gears fps now, not gltron, right? ok gears does 160 >software now on my Duron 800, while on Mach64-accel it does 260. >gltron does 5-15 on mach64, 5-15 on plain mesa, too; although it >subjectively seems to be a bit jerkier. Anyway, with the old Utah >code I got more (at least 20fps, but on a K6-2 333) but that has >time. I'm more concerned about glxgears: in software mode, it shows >the three gears moving; in hardware mode, it just shows a huge >close-up of the red one moving. Strange, since gltron looks almost >equivalent under both modes, with hardware having a bit better >texture filtering IMHO. BTW, why does mach64 module insertion >fail when agpgart isn't installed if it doesn't use any features >from AGP? > >HTH, Yours Malte #8-) > >PS: no need to Cc me, I'm on this list. > >___ >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
Re: [Dri-devel] Mach64: mach64-0-0-2-branch created and updated
On Mon, Oct 22, 2001 at 11:19:41PM -0400, Carl Busjahn wrote: > Hello, > The Mach64 driver calls for agp, which is why it's failing, I suppose > that you could take out that call for machines with PCI cards, but > AGPgart won't mess up machines even without AGP chipsets. What kind of With Mach64, perhaps. With Radeon PCI, it locks up horribly in Xserver initialization. R C -- They said it was *daft* to build a space station in a swamp, but I showed them! It sank unto the swamp. So I built a second space station. That sank into the swamp too. My third space station sank into the swamp. So I built a fourth one. That fell into a time warp and _then_ sank into the swamp. But the fifth one... stayed up! --Monty Python/Babylon 5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64: mach64-0-0-2-branch created and updated
On Tue, 23 Oct 2001, Malte Cornils wrote: [snip] > gltron does 5-15 on mach64, 5-15 on plain mesa, too; although it > subjectively seems to be a bit jerkier. Anyway, with the old Utah code > I got more (at least 20fps, but on a K6-2 333) but that has time. I'm > more concerned about glxgears: in software mode, it shows the three > gears moving; in hardware mode, it just shows a huge close-up of the > red one moving. Strange, since gltron looks almost equivalent under > both modes, with hardware having a bit better texture filtering IMHO. > BTW, why does mach64 module insertion fail when agpgart isn't > installed if it doesn't use any features from AGP? Are you sure gltron is using the right libGL? You should see something like this on the console when you run gltron: OpenGL Info: 'Gareth Hughes' Mesa DRI Mach64 20001218 [Rage Pro] x86 - 1.2 Mesa 3.4.2 I tried gltron 0.59, and with alpha blending off (there seems to be a problem here -- with it on you can't see most of the cycles/trails), I'm getting ~25-30 fps average on my 400MHz PII laptop at 640x480 windowed, 16bpp, whereas with software I get about 2 fps (even the menus are horribly slow). Also, what bit depth are you using? 16 works for me much better than 24 (which can only do 800x600 with DRI for me). At 24bpp I get overlapping screens (buffer clear problem?) and a strange 'silkscreen' kind of effect on some textures. At 16bpp I also have texture problems in q3demo (I see white walls/floors, no textures but damage textures from weapons show up over the white) and the above mentioned problem with alpha blending. I did a little research and here's some more info on the state of the driver... Heres one of Gareth's last log entries (2000/12/17) from the original mach64 branch: Hardware accelerated rendering for the Rage Pro. Client-side PIO with texturing, enough to play Q3A 'Fastest'. Multitexture not working correctly at this stage, no lines or points, bits of state missing etc. Should run most of the Mesa demos. I will make a full post to dri-devel regarding the current state of the driver, so please see that for more information. I tracked down the post (Geocrawler, yech!): To prevent a whole bunch of people emailing me and asking me about this (ie. please don't email me and ask me about this!), here's some info on the Rage Pro driver I just committed. The mach64-0-0-1 branch code now does full hardware-accelerated rendering of tris and quads (no lines or points yet). Texturing is supported, but multitexture is slightly broken. There are undoubtedly bits of state that aren't being set up correctly, which will result in incorrect rendering of primitives, but on the whole it should cope with most of the Mesa demos. I have been able to play Quake3 on 'Fastest' settings, and get a timedemo of around 30fps with my 600MHz Duron system (pure brute force here, the driver is slow due to lack of DMA). There are some minor glitches, but it works fairly well. Now for the instructions: This is EARLY DEVELOPMENT WORK. It is buggy and incomplete. Therefore, DO NOT email me if you have problems, if it crashes your machine, whatever. I will at best ignore all such emails. I'd rather spend time working on the driver than answering support emails at this time. This driver is COMPLETELY INSECURE. The client-side driver is doing register programming, which is pure evil. I take no responsibility for any damage that may be done to your system by running the driver at this early stage of development. Having said that, feel free to check the driver out. This work is being done on my spare time, and thus there will never be any timeline for release. I will continue working on it if/when I have the time. -- Leif Delgass ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64: mach64-0-0-2-branch created and updated
> At 16bpp I also have texture problems in q3demo (I see white > walls/floors, no textures but damage textures from weapons show up > over the white) and the above mentioned problem with alpha blending. The q3demo texture problem only appears with lightmap lighting -- vertex lighting works fine. -- Leif Delgass ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64: mach64-0-0-2-branch created and updated
El Mar 23 Oct 2001 06:17, Leif Delgass escribió: > On Tue, 23 Oct 2001, Malte Cornils wrote: > > [snip] > > > gltron does 5-15 on mach64, 5-15 on plain mesa, too; although it > > subjectively seems to be a bit jerkier. Anyway, with the old Utah code > > I got more (at least 20fps, but on a K6-2 333) but that has time. I'm > > more concerned about glxgears: in software mode, it shows the three > > gears moving; in hardware mode, it just shows a huge close-up of the > > red one moving. Strange, since gltron looks almost equivalent under > > both modes, with hardware having a bit better texture filtering IMHO. > > BTW, why does mach64 module insertion fail when agpgart isn't > > installed if it doesn't use any features from AGP? This is an interesting problem. How are other drivers dealing with this? I suppose that the mach64 driver only should try to load the agpgart when the card is agp based. I'm trying to see how could this be made. > OpenGL Info: 'Gareth Hughes' > Mesa DRI Mach64 20001218 [Rage Pro] x86 - 1.2 Mesa 3.4.2 > > I tried gltron 0.59, and with alpha blending off (there seems to be a > problem here -- with it on you can't see most of the cycles/trails), I'm > getting ~25-30 fps average on my 400MHz PII laptop at 640x480 windowed, > 16bpp, whereas with software I get about 2 fps (even the menus are > horribly slow). Also, what bit depth are you using? 16 works for me much > better than 24 (which can only do 800x600 with DRI for me). At 24bpp I > get overlapping screens (buffer clear problem?) and a strange 'silkscreen' > kind of effect on some textures. At 16bpp I also have texture problems in > q3demo (I see white walls/floors, no textures but damage textures from > weapons show up over the white) and the above mentioned problem with alpha > blending. > Mesa DRI Mach64 20001218 [Rage Pro] x86 - 1.2 Mesa 3.4.2 > > I tried gltron 0.59, and with alpha blending off (there seems to be a > problem here -- with it on you can't see most of the cycles/trails), I'm > getting ~25-30 fps average on my 400MHz PII laptop at 640x480 windowed, > 16bpp, whereas with software I get about 2 fps (even the menus are > horribly slow). Also, what bit depth are you using? 16 works for me much > better than 24 (which can only do 800x600 with DRI for me). At 24bpp I > get overlapping screens (buffer clear problem?) and a strange 'silkscreen' > kind of effect on some textures. At 16bpp I also have texture problems in > q3demo (I see white walls/floors, no textures but damage textures from > weapons show up over the white) and the above mentioned problem with alpha > blending. I have no one of the OpenGL demos installed but gears. I'll try to compile them to compare your results. Anyway, what I'm impatient to see is the results with the DMA working. Frank, when do you think you'll have time to start this work? I've been looking at the mga and the i810 driver, but I'm not seeing it clear. In the UTAH-GLX driver there were two dma buffers, true? Should we use a freelist in the DRI driver for the mach64? When should the DMA buffers be sent to the hardware? Could different clients have different DMA buffers simultaneously? Is the mga a good example to start to look at? Is the card similar to the mach64? Another WORK TO DO, is to allow 2D accelerated rendering and 3D at the same time (actually the 2D acceleration is disabled in the driver). Why must it be disabled now? What should be done to fix this? As you can see, I'm a see of doubts. Best regards. -- Manuel Teira ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64: mach64-0-0-2-branch created and updated
On Monday 22 October 2001 18:58, Malte Cornils wrote: > BTW, why does mach64 module insertion > fail when agpgart isn't installed if it doesn't use any features > from AGP? While we're opening the device, we're not using it because the code that we have was stalled at DMA operations (It's just the way Gareth was coding it at the time he was working on it)- we'll get to it shortly. Right now, we're migrating what's already there to use the DRM properly (since it's just doing direct writes to the register right now...). -- Frank Earl ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64: mach64-0-0-2-branch created and updated
On Monday 22 October 2001 22:41, R C wrote: > With Mach64, perhaps. With Radeon PCI, it locks up horribly in Xserver > initialization. There could be several reasons for that- the code should be checking for the lack of AGP support and do the right things. As for it needing it to be loaded, we probably ought to do something like Utah-GLX does for textures, etc. so that we can get this off the ground for people with PCI setups while we look into what it'd take to do PCIGART type work for this driver. -- Frank Earl ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64: mach64-0-0-2-branch created and updated
On Tuesday 23 October 2001 11:28, Manuel Teira wrote: > This is an interesting problem. How are other drivers dealing with this? I > suppose that the mach64 driver only should try to load the agpgart when the > card is agp based. I'm trying to see how could this be made. The Utah-GLX code's got a good example of this- just check to make sure that the DRM infrastructure code (in the drm* files) isn't the one doing the loading and it's the Mach64 code doing it. > Anyway, what I'm impatient to see is the results with the DMA working. > Frank, when do you think you'll have time to start this work? I've been > looking at the mga and the i810 driver, but I'm not seeing it clear. In the > UTAH-GLX driver there were two dma buffers, true? Should we use a freelist > in the DRI driver for the mach64? When should the DMA buffers be sent to > the hardware? Could different clients have different DMA buffers > simultaneously? I just checked it out last night. I've got to get it where it's compiling so it may be a day or so before I get to any DMA changes. I'm thinking something along the lines of a freelist if it doesn't have too much overhead- but it's going to be largish blocks- from my testing of games for Loki, I've discovered that each pass can use upwards of 512k or more per frame. Better performance is obtained with _long_ lists for the chip to operate against as it allows the CPU to be doing other tasks longer. It's a compromise- you want the longer lists, but you don't want the CPU to be waiting for a free list space too long so you try to pick a decent size and offer up enough slots for it to basically fly. As for when they should be sent, well, it should be at the end of each frame (Mesa knows this and the driver's likely to have a stub for the function called) and when a buffer is really, really close to full (Taken care of by either the driver or the DRM- I'll have to look a little further at the DMA code in the other drivers to get a better idea of who's responsibility it is...). > Is the mga a good example to start to look at? Is the card similar to the > mach64? For the DMA API, perhaps. The RagePRO is an interesting beastie- it doesn't quite work like most of the other cards. Unlike many of the cards that offer DMA support that I've seen, it does scatter-gather operations. This means that we don't need a linear space and we can hand it huge tables of commands (4096 4k pages with a 16k descriptor table- larger descriptor tables are possible...) In some ways, it makes our lives easier, in others it's more interesting. > Another WORK TO DO, is to allow 2D accelerated rendering and 3D at the same > time (actually the 2D acceleration is disabled in the driver). Why must it > be disabled now? What should be done to fix this? Implement the DMA interface, implement proper DRM locking for the DMA pass (and verify that the 2D code is honoring the DRM locks...), and re-code the Mesa layer driver to use the new DMA interface. Implementing the interface code is my current priority as I see it- this way you or someone else can re-work the rest of the code. -- Frank Earl ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
