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])
*** Did you ever wonder: how to turn your virge powered pc to a 3d workstation? **************** *** about it *** **************** Hello, world. Since you wont normally know anything of me but my code, let me introduce myself to you: my name is Massimiliano (max) Lingua, and I am a spare-time programmer. In the real life I am a philosopher (ontology and quantum logics) and I am studying laws to eventually become a lawyer (software licenses and corporation law). In the last months I programmed a driver (or better the three parts of it: the drm kernel module, the DRI extension for the X module and the DRI/GL library) for the gfx card [S3 Virge/MX+MV 4MB] I have in my notebook, since I enjoy OpenGL programming (video morphing) but 3d acceleration of my gfx card was no longer supported in XFree-4 and the utah version was buggy, partial and XFree-3 only (but times are a-changing, have a look at utah-glx.sf.net), nor could I afford to buy a new laptop in short time. So here is what we have (hw accelerated, of course) a) 3d primitives (flat/gouraud triangles and lines) b) z-buffering c) alpha-blending (for all the modes supported by virge) d) texturing (for all the format and filter modes supported by virge) Still not implemented are: e) fog (hw fog is not compatible with hw alpha, so I chose the latter. It could still be implemented in sw, though) f) lighting (I don't honestly understand how to implement it ; ) g) hw clipping (it will give us some speed boost, but I don't know how to handle it in Mesa/DRI. Any info about it is welcome) *** Strenght points *** [DONE] 1) speed is amazing. Glxgears gives me a 130 frame/sec on my PII-233 notebook, and if you turn gears to just see the thin profile you will get ~175 fps. Alas, speed is that high only for apps with few static textures and with small windows. See under. Nevertheless some psx games (I am running epsxe as an emulator with some of my younger brother's games] run quite fast: Spyro the dragon (10->14 fps); Deathtrap dungeon (3->23 fps) (just keep in mind we are emulating another cpu too...) 2) fully DMA based, 8x2 64K DMA buffers (2 per apps [maximum 8], bouncing buffers) so your cpu won't be hogged writing to card registers. 3) single and double buffering 4) multiple opengl apps (maximum 8) are supported but with some limitation. If the application draw complex scenes that will fill more than one DMA buffer (64k) it could happen that relevant [like stride] informations are overwritten by another application running concurrently [and with different stride]. This could be solved by starting every buffer with a header containing the sensible infos for the app. To see this try running (these demos are in "glutdemo" package form SuSE) more instances of "atlantis" (up to 8). Everything should be OK. Now try some "newave" with default detail [size=medium]. You see the problem? Try lowering the details [size=small] ; ). Result will depend on your cpu power too: if everything else fails, try reducing windows sizes. *** Weak points *** [TODO] 1) interaction with X is bad, you will have to: - run X at 15 bits (but this is a virge limitation) - turn off 2d acceleration (I coded a lock [the kernel semaphore s3v_gfx_sem] in the drm module, but I don't know how to make X to hold it when it is doing 2d accelerated drawing. By fixing this, we could easily enable all the accelerations since 3d won't paint when this lock is hold) - be very patient with windows interaction: opengl app will run on the top of everything else, leave sometimes garbage if you move them around. Some window won't ever move or resize (try glxgears) its content at all. 2) depth comparison between lines and triangles is wrong (try "origami" example) 3) other mathematical imprecisions (e.g. sometimes you will see some garbage between the two textured triangles composing a quad. Try "skyfly" and have a look at th sky) 4) speed issue with many textures: texture loading is slow and unaccelerated (we just copy textures bit by bit to virge memory and we don't do DMA. This could be fixed by someone with some knowlegde of MMX asm: it will give us the necessary boost) 4) speed issue with large windows: we are blitting instead of double-buffering (we are in window mode, otherwise we could resort to Streams processor to double buffer). It would be nice to have a fullscreen mode using Streams. 5) fog ang lighting. 6) some problem with clipping. Try "bluepony" from glutdemos (the clipped squares have weird double color) or "battalion" - the classic 3d game (start with Coogelon [the red drake (6)], push 'd' until you get the wireframe mode, then choose '1' for visual mode. You will see: half of our beloved monster is missing). This two should automatically get fixed if we could get hw clipping working in DRI. 7) *** BAD *** virge random lockups [should be fixed know, but not sure]. In a non-stochastic way your virge will soon or later lock up hard [your machine won't answer to a ping, and you will have to pull your notebook battery out to turn it off!]: sometimes after a few second sometimes after many hours. The best way to lock it up is to run Quake2 (through q2hack). I tried -everything I could think of- to fix this one, but in vain. I tried turning off (in my code by simply making functions to immediately return) textures, spans [which implies a direct write to card memory] and locking [I feared it could loop] but nothing of nothing. This is the point where I greatly need some help (any electronical engineer out there?) hoping this is not an hardware misfeature: on my notebook virge don't even support interrupt so I had to resort to polling DMA status ;( 8) multi apps deadlock. Try leaving 2 "glxgears &" running concurrently for some minutes. Note: you won't be able to move the window, so to perceive the second app, just resort to cursor keys to spin its content -> after a short while the kernel should deadlock (the drm module is in a loop, but the machine is not dead: I can still use the power off button to shut it down;-) 9) psx videos bug. In many psx games videos (like the one in Final Fantasy VII intro: it rocks to the amazing speed of 10-22 fps! but the game will score an awful 4-7 fps...) the screen part to the left will mimic the part to the right, like the wrong texture would have been applied. Che fare? [italian for: what should I do?] Things I could be involved are: X locking mechanism (to enable 2d acceleration again), textures speed enhancements, fixing random lockups and kernel module deadlocks. Please don't ask me to fix other bugs, they are not relevant to me and I don't think I am going to fix them any soon in the future. I already did the greatest part of the job, anyone else volunteers now? ********************** *** how 2 build it *** ********************** NOTE: berfore you start: you will need DRI mesa-4.0 tree to correctly compile the OpenGL part of my code. It has still not been merged in actual XFree-4.2.0. So cvs it from dri project [dri.sf.net]. cd xc/xc vi config/cf/linux.cf [check defines are ok (they should) for you] vi config/cf/host.def [add s3virge in #define XF86CardDrivers] cd programs/Xserver/hw/xfree86/drivers mv s3virge/ s3virge.orig/ [backup] tar xvfz [PATH/]s3virge-20020308.tgz cp s3virge/xf86drmS3V.c ../../../../Xserver/hw/xfree86/os-support/linux/drm [= xc/xc/programs/Xserver/hw/xfree86/os-support/linux/drm] cp s3virge/xf86drmS3V.h ../../../../Xserver/hw/xfree86/os-support [= xc/xc/programs/Xserver/hw/xfree86/os-support] cp s3virge/drm_Imakefile ../../../../Xserver/hw/xfree86/os-support/linux/drm/Imakefile [= xc/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/Imakefile] cd ../../../../.. [=xc/xc] cd programs/Xserver/hw/xfree86/os-support/linux/drm mv kernel/ kernel.orig/ tar xvfz [PATH/]kernel-20020308.tgz [note: if you are not using the latest dri cvs, be sure to comment out all instance of *i830* driver (include, ioctls) in drm.h. For your safety I already commented those out in my version] cd ../../../../../../.. [=xc/xc] cd lib/GL/mesa/src/drv tar xvfz [PATH/]GL_20020308.tgz cp s3v/GL_Imakefile ../../../dri/drm/Imakefile cd ../../../../.. make World >& world.log [it will take a some time + some hd space] cd programs/Xserver/hw/xfree86/drivers [become root] cp s3virge_drv.o /usr/X11R6/lib/modules/drivers cd lib/GL/mesa/src/drv/s3v [if something went wrong during previous compilation, be sure to do here: xmkmf -a ../../../../../..; make] [become root] cp s3v_dri.so /usr/X11R6/lib/modules/dri cd programs/Xserver/hw/xfree86/os-support/linux/drm [become root] cp libdrm.a /usr/X11R6/lib/modules/linux NOTE: be sure the libGL.* you are using is the DRI one; if you are in doubt use the one in: xc/xc/lib/GL/GL [libGL.so.1.2] NOTE: use the SGI glu version, otherwise many demos (expecially the one using GLE library) wont correctly work ************************** *** how 2 configure it *** ************************** *** S3 VIRGE DRM See s3v_dma.c. You can turn on S3V_DEBUG (for specific virge dma debug) and fine tune the udelays with S3V_UDELAY macro (I set it to 1 sunce it works fine for me: if you fear you are hammering the gfx card, you could try rising it up). *** S3 VIRGE DRI/GL [s3v_tex.h] _TEXFLUSH 1 will flush DMA buffers before altering texures state (e.g. swapping'em out); _TEXLOCK 1 will lock the gfx card before writing new texures to card mem; _TEXFALLBACK 1 will fallback to software for big texs that won't fit card mem devoted to textures. My default is _TEXFLUSH 1 / _TEXLOCK 1 (sice that seems to avoid many lockups) _TEXFALLBACK 0 (otherwise many games, like tuxracer [you will just loose the mountain pic in the background] will run too slow to be playable). [s3v_span.c] _SPANLOCK 1 will lock the gfx card before writing of spans to card mem. My default is _SPANLOCK 1. Usually turning locking will loose some performance (10-20%) but will make things more robust. So the choice is yours. *** XF86Config (XFree-4) [Section "Module"] be sure to add Load "dri" Load "glx" [Section "Device"] be sure to add Option "NoAccel" "1" (will disable 2d accel) Option "SWCursor" "1" (slower again, but more robust) Option "backbuffer_size" "(1)" [see under for explanation] Option "texbuffer_size" "(2)" [idem] (1) insert here how much card mem (in bytes) you will devote to backbuffer. My default (for a virge/mx with 4mb) is "960000". This will give me a maximum of 800x600 window at 16bpp (=800x600x2). (2) insert here how much card mem you will devote to textures. My default is 640k (="655360" bytes) [Section "Screen"] be sure to add DefaultDepth 15 and to have a Subsection "Display" fo 15bpp, mine is Subsection "Display" Depth 15 Modes "800x600" "640x480" ViewPort 0 0 EndSubsection *********************** *** repetita iuvant *** *********************** Things I could be involved are: X locking mechanism (to enable 2d acceleration again), textures speed enhancements, fixing random lockups and kernel module deadlocks. ***Please*** don't ask me to fix other bugs, they are not relevant to me and I don't think I am going to fix them any soon in the future. I already did the greatest part of the job, anyone else volunteers now? vale, yours, - max lingua ([EMAIL PROTECTED]) P.S: next summer I will code DRI/DRM for Savage, and try to port FireGL1 driver from Intel to PPC (if they will give me access to the source).