nVidia 3D add-on with Mesa 3.2.1 README (R5 and Max)



This is the alpha 3.5 release of the nVidia 3D add-on driver including Mesa 3.2.1 library for R5 and Max edition. This driver requires 2D driver 0.67 in order to work (otherwise your system will hang). Make sure you let the 2D driver use it's default DMA mode for acceleration: it's preset in nv.settings. If you used the Alpha 1 3D add-on you need to update the nv.settings file as that one used PIO mode! Reboot after installing the 2D driver: only after a reboot will the new driver be in effect and can 3D applications be used successfully.

Status since Alpha 3:


The info below was not updated for Alpha 3.5, it still reflects Alpha 3 status.

Status since Alpha 2:



Installing the 3D add-on is nothing more than moving or copying the two libraries libGL.so and libGLU.so into the ~/config/lib folder. For convenience, I added the 2D driver 0.53 including a correctly preset nv.settings file in the archive. Also included are precompiled demo applications.

If, while testing, you hang your system, you should hit ALT, CTRL and DEL simultaneously (and keep that pressed down for a few seconds) to reboot. If it turns out you cannot run the driver/library just delete the files libGL.so and libGLU.so from your ~/config/lib folder and you should be OK. Without even rebooting: as those libraries are only loaded while you run an app using it.

If you test this 3D add-on you are encouraged to provide feedback. Feedback will tell us best what the actual useability of this attempt is in the end, and where additional fixes are needed. Feedback can be sent by Email or by talkback on the BeBits entry that I have created for this 3D driver.

OK, below you'll find a table containing the status of the driver, followed by a table indicating the status of that driver for several applications. I hope it's all of use to you! Have fun...


Table: Driver version 'alpha 3' status.

Item:

Status:
Accelerated libraries
  • libGL.so is accelerated and contains the 3D add-on driver.
  • libGLU.so is a utility library that runs on top of libGL.so, it contains no internal acceleration. If libGLU accelerates, it does so by using libGL.
Engine access type DMA mode. You want this. Believe me ;-)
Supported colordepths 16 and 32 bit modes are fully working, 15 bit mode is partially working. 8 bit mode isn't implemented yet. At least 15 bit mode will be completed, but not before switching to Mesa 6.2.
Supported cards NV04 (TNT 1) upto and including (the now fast performing) NV18 (GeForce 4MX). I'll try to get more modern cards up in the future. Currently the driver blocks use on NV20 and higher.
3D Rendering functions Straight and AA (anti-aliased) point and line functions. Straight triangle function: Although Mesa 3.4.2 supports AA triangles, it isn't implemented in the driver yet: it will use non-AA instead. Support for AA triangles will be setup later if possible (engine command is known), after we switch to Mesa 6.2.1. The Depth (Z) buffer is fixed at 16 bit depth.
3D Texturing Single texturing is supported. Multiple texturing will be setup later if possible (engine command is known).
3D States
  • Line and Polygon stippling is not supported (driver falls back to software rendering mode so it renders OK but is slow);
  • Stencil buffering is not supported (driver falls back to software rendering mode);
  • Drawing into the frontbuffer is not yet supported (driver falls back to software rendering state);
  • Single buffering is not yet supported (driver will probably not work at all).
3D driver's 2D Functions
  • Swapbuffers() is accelerated for both BWindow (non-direct) and BDirectWindow (direct) modes;
  • Triple buffering could be setup later on (Be's libraries do that? Or do they 'just' 'fallback' to the backbuffer as source for intermediate frontbuffer updates like Mesa 6.2.1 does?). Triple buffering could probably be an easy fix for 'single buffered' contexts (which will actually be double buffered then), and it helps out for slow rendering apps when you move their windows off- and then onscreen again. The Alpha 2 driver copies the backbuffer to front in such a case just like Mesa 6.2.1 does. The downside is that you might see a partially rendered advance copy of the 'new' backbuffer during a short time. Anyway: much better than no update at all ;-)
    Non-direct BWindow mode will not work correctly even when we use BGLView's Invalidate() and Draw() functions for 'back' to front rendering instead of doing that in Swapbuffers() (confirmed by testing now). We really need to loose support for Non-direct mode!;
  • Swapbuffers() uses 2D blits, even for fullscreen. Literal swapping for fullscreen apps might be setup later (engine commands are known). Gain is not much: in 640x480x16 mode an example speed of Q2 is 119fps which stays exactly the same, while upto 1fps is gained in 1024x768x32 mode (23.2 goes up to 24.2fps, so 4.3% gain here: tested with old Alpha2-final);
  • In direct BDirectWindow mode the DirectConnected() clipping_info turns out to be working after all! (apart from the BMenuBar error for which I have a workaround in place). This means you can drag direct windows like a madman, without errors appearing onscreen ;-)
  • In non-direct BWindow mode drawing errors will be made of you move the application window to fast, or if you move other windows over the application window to fast. This cannot be fixed. Period.
  • Scaling is not yet supported: if you resize output windows you will see repeating patterns or rubbish in the extra 'room' (sizing up), or you will see only part of the applications output (sizing down). Will be fixed for a future release. Mesa 3.4.2 contains an internal error which prevents resizing of buffers to work correctly. Mesa 6.2.1 is confirmed to be OK in this respect though: I should just need to add one extra flag to the BGLView constructor: B_FRAME_EVENTS. Want to test software rendering for this on Mesa 6.2.1? Just add that flag to the BeOS driver included in that release..
BView's function activation Be's flags B_WILL_DRAW and B_PULSE_NEEDED are required for BGLView: some applications rely on it without explicitly issuing them. These flags are hardcoded added by the driver when an application creates a BGLView. B_FRAME_EVENTS will be added here later. For now it's commented out because the driver/mesa combi are highly unstable when resizing buffers, just like the original software-only Mesa 3.4.x. (Mesa 6.2.1 should be OK though, confirmed software mode after adding that flag.)
Table: Driver version 'alpha 3' status.


Table: Status for tested applications.

App name:

Location:

Status:

Mode:

Faults:

Driver or library failsafe:
3Dlife Optional sample code Working as is BWindow/non-direct mode Doesn't call glViewport() Driver calls glViewport() while servicing a backbuffer clear command when it detects no backbuffer was created before. glViewport() takes care of creation among other things.
GLteapot Optional sample code Working after relinking BDirectWindow/direct mode None Relinking against both libGL.so and libGLU.so is required because some items used are in libGL.so these days, while being in libGLU.so at Mesa 3.4.2 'time'. We are 'going back in time'.
Demo Mesa 3.4.2 Working after fix BWindow/non-direct mode Doesn't call glPopMatrix() Added glPopMatrix() to the application. A library failsafe can be done in theory, but it requires additional code. It would need to check if the stack still contains a Matrix when Swapbuffers() is called (or so). Checking would be state-dependant.
Sample Mesa 3.4.2,
BeBook: openGL kit, BGLView 		Working as is BWindow/non-direct mode None None
GLQuake for BeOS R4.5 running on R5/dano http://www.aixplosive.de/projects.html Partially working as is BDirectWindow/direct mode Yet unknown This application doesn't work correctly for a number of reasons:
  • It sometimes renders directly to the frontbuffer which the driver doesn't really support yet;
  • It crashes when using the keyboard: this seems a Mesa 3.4.2 fault: Be's lib is working OK, while the full software Mesa 3.4.2 fails as well;
  • Some bitmaps are rendered in wrong colors: This seems a driver fault: rendering triangles requires more state-checking (for getting color-info, among others probably);
  • The picture 'flickering' error is now fixed (due to the Mesa upgrade: Mesa 3.4.2 handles this OK apparantly).
Quake II V3.20 http://www.bebits.com/app/1712 Working as is, with some displaying errors caused by Mesa 3.4.2. (Full software Mesa 3.4.2 has the same errors.) BDirectWindow/direct mode Doesn't call LockGL() Driver calls LockGL() in the BGLView constructor if gl_get_current_context() returns NULL. Probably needs to be done elsewhere ('later') in the driver so it's actually possible that a context was indeed made current by calling LockGL() at some point in time.
Table: Status for tested applications.


As you can see from all info listed above, the general idea for a 3D library apparantly is to make it work even if the application developer forgets to do some things officially needed. At least this is the road Be took. The downside of that is of course, that certain mistakes otherwise easily located might never be found now...

Having said that, I'll try to be as compatible as can be with the Be (software) libraries (BGLView). For now: have fun!


Rudolf.

(Page last updated on August 8, 2005)