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).

Reply via email to