Introducing the fastest, most efficient way of getting 3D acceleration into your graphics, the direct rendering infrastructure for framebuffer consoles.

  • FBDRI can run independant of any 2D windowing system. You don't have to load 2D windowing and user interface code if you don't need it.
  • OpenGL programs that use FBDRI instead of XF86DRI require much less memory since Xlib, the XServer, and all the X extensions are removed.
  • FBDRI programs can have larger visuals and textures than X because no offscreen memory is reserved for anything else and we can easily kludge the memory manager.
  • FBDRI can potentially be much easier to configure than X. Although the current draft has a lot of hard coding, all you need to theoretically worry about is the framebuffer modeline and color depth.
  • We can do lots of strange and unusual things much more easily under FBDRI than under X, like directly writing to texture memory over mmio, overlapping texture buffers to simulate more memory than we really have, implementing 2D windowing systems inside textures.


    FBDRI is an easy way to support 3D graphics in the Framebuffer console, yet it is not a new OpenGL implementation written from scratch.

    Rather we reused the GLX and XF86DRI code and performed significant modifications to run it independantly of a 2D windowing system. Despite the modifications, the reuse of XF86DRI makes it possible to support 3D in the framebuffer console shortly after any new X windows driver comes out.

    Although the current FBDRI draft relies on SDL for visual initialization and user input, FBDRI is designed to function independant and parallel of the windowing system, thus there are no SDL dependancies in it. You could easily write your own initialization calls to the framebuffer device and transfer control to pure FBDRI in less than 64k of memory.


    Currently FBDRI only works with the following chipset:

    ATI Radeon with 64MB
    ATI Radeon with 32MB

    Since we're not planning to use any other chipset at the office, further ports would have to come from outside.

    Either way, our installation directions are specific to radeon.

    Sourcecode to download:

    FBDRI tarball

    This contains an SDL and a DRI directory. They should both get uncomressed side by side somewhere. Then you should make in SDL and make in DRI.

    Once the top level Makefiles are finished, go into dri/os-support/linux/drm/kernel and run make again.

    So now you have four important objects:

    sdl/src/.libs/libSDL* - SDL windowing system hacked for FBDRI.
    dri/i686/ - OpenGL implementation using FBDRI.
    dri/i686/kernel/radeonfb.o - kernel framebuffer driver hacked to enable bus mastering.
    dri/os-support/linux/drm/kernel/radeon.o - kernel DRI/DRM driver hacked for FBDRI.

    If it succeeded in building a test program, congratulations, otherwise you'll have to write your own test program.

    To run the test program you need to load some kernel modules.

    insmod i686/kernel/radeonfb.o This probably depends on packed pixel modules in your /lib/modules directory. Obviously your kernel needs support for framebuffer devices enabled.

    insmod os-support/linux/drm/kernel/radeon.o

    Edit the LD_LIBRARY_PATH in runtest to point to your sdl/src/.libs and your dri/i686 directories. Then run runtest preferrably by remote login from another computer.

    Hit a key to quit the program. It doesn't restore the console so you'll have to reboot to get it back.


    081201: Initial release. 64MB Radeon only.

    082201: This should theoretically support Radeons with 32MB as well as 64MB. C++ as well as C programs should now compile for FBDRI. Some functions not implemented in 081201 should now work. Also the waiting and cache flushing was disabled from the DRM kernel module. This speeds it up by 10% without appearing to cause any problems.


    If you plan to develop for FBDRI the include directories are different:

    sdl/include - SDL header files
    dri/include/GL - OpenGL header files

    You must use these include files instead of the traditional system includes because the SDL structures are different sizes to support FBDRI and the GL functions were mapped directly to FBDRI using macros, not assembly language symbol redirection like X Windows.

    You must link the following libraries:



    Unlike XF86DRI where you had a lot of functions to pointers indirecting 95% of the calls, FBDRI ports should rely on symbol reuse. Future FBDRI ports should rename the RADEON*, drmRadeon, etc calls to generic DRIVER, and drmDriver calls, thus by linking different object files for DRIVER and drmDriver functions you eliminate indirection and make the code much easier to read. The FBMesa calls already do this.

    We've taken all the relevant DRI code from the XFree86 tree and assembled it in the dri directory. A single top-level Makefile compiles everything in all the dri subdirectories except os-support/linux/drm/kernel/.

    "FBDRI_Main *dpy" replaces all "Display *dpy" and most of the visual/screen/drawable instances for now.

    Currently some of the variables are hard coded to speed up the FB porting. Variables like PCI bus ID.

    Wherever an X structure is needed, values are set in the FBDRI_Main structure, to be initialized in the FBDRIScreenInit command. This is called by whatever initializes the framebuffer console, in our case SDL.

    All X11 dependancies which can't be removed have to be implemented in the FBDRI_Main object.

    Spagetti for sending requests to the X Server are gone.

    Version checking is gone, probably to be reintroduced later.

    The kernel level driver is straight from xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel. Minor changes are done to improve verbosity and work around some X Server dependancies.

    Mappings between the X11 dri directories and the FB dri directories.

    We try to adhere to the original directory structure to minimize confusion.

    xc/include/GL -> include/GL
    xc/extras/Mesa/include/GL -> include/GL
    xc/lib/GL/dri -> lib/GL/dri
    xc/lib/GL/glx -> lib/GL/glfb
    xc/lib/GL/mesa/src/drv/ -> lib/GL/mesa/src/drv/
    xc/lib/GL/mesa/dri/ -> lib/GL/mesa/dri
    xc/programs/Xserver/hw/xfree86/os-support -> os-support
    xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel -> os-support/linux/drm/kernel
    xc/programs/Xserver/hw/xfree86/drivers/ati -> drivers/ati/
    xc/programs/Xserver/GL/dri/ -> dri/

    You'll find that the driver specific definitions tend to stay in

    dri/lib/GL/mesa/src/drv - user-space XF86DRI driver

    dri/os-support/linux/drm/kernel - kernel-space XF86DRI driver

    dri/drivers/ - segments of the XFree86 2D driver required by DRI

    The dri source code documentation, except for the Jens Owen parts, is pretty bad, with many indirections making it hard to follow. Most of the indirections should be eliminated in FB dri and a monolithic binary created for each card.

    Rough idea of the control flow in the X Server DRI:

    X Server initialization calls this
    radeon_driver.c: RADEONScreenInit
    	radeon_dri.c: RADEONDRIScreenInit
    		dri.c: DRIScreenInit
    			dri.c: DRICreateContextPrivFromHandle
    		dri.c: RADEONDRIMapInit
    		dri.c: RADEONInitVisualConfigs
    SDL_video.c: SDL_SetVideoMode
    	SDL_x11video.c: X11_SetVideoMode
    		SDL_x11video.c: X11_CreateWindow
    			SDL_x11gl.c: X11_GL_CreateContext
    				glxcmds.c: CreateContext (glXCreateContext)
    					glxext.c: __glXInitialize
    						dri_glx.c: driCreateDisplay     // Bind the __driCreateScreen functions to pointers
    						glxext.c: AllocAndFetchScreenConfigs
    							dri_mesa.c: __driCreateScreen (createScreen)
    								dri_mesa.c: driMesaCreateScreen
    									radeon_xmesa.c: XMesaCreateVisual
    									radeon_xmesa.c: XMesaInitDriver
    										radeon_screen.c: radeonCreateScreen
    					dri_mesa.c: driMesaCreateContext (createContext)  // The dri context.
    						gl_create_context      // The mesa GL context inside the dri context
    						radeon_xmesa.c:  XMesaCreateContext (CreateContext)
    							radeon_context.c: radeonCreateContext
    	SDL_x11gl.c: X_GL_MakeCurrent (GL_MakeCurrent)
    		glxext.c: glXMakeCurrent
    			dri_mesa.c: driMesaBindContext
    					radeon_xmesa.c: XMesaCreateWindowBuffer
    Rough idea of the control flow in FB DRI. Most of these calls should be direct:

    SDL_video.c: SDL_SetVideoMode
    	SDL_fbvideo.c: FB_SetVideoMode
    		dri.c DRIExtensionInit
    		fbdrimain.c: FBDRIScreenInit
    			radeon_dri.c: RADEONPreInitDRI
    			radeon_dri.c: RADEONDRIScreenInit
    				dri.c: DRIScreenInit
    					dri.c: DRICreateContextPrivFromHandle
    				dri.c: RADEONDRIMapInit
    				dri.c: RADEONInitVisualConfigs
    			radeon_dri.c: RADEONDRITexturesInit
    			radeon_dri.c: RADEONDRIFinishScreenInit
    		glfbcmds.c: glFBCreateContext
    			glfbext.c: __glFBInitialize
    				dri_glfb.c: driCreateDisplay     // Bind the __driCreateScreen functions to pointers
    				glfbext.c: AllocAndFetchScreenConfigs
    					dri_mesa.c: __driCreateScreen (createScreen)
    						dri_mesa.c: driMesaCreateScreen
    							radeon_fbmesa.c: FBMesaCreateVisual
    							radeon_fbmesa.c: FBMesaInitDriver
    								radeon_screen.c: radeonCreateScreen
    			dri_mesa.c: driMesaCreateContext (createContext)  // The dri context.
    				gl_create_context      // The mesa GL context inside the dri context
    				radeon_fbmesa.c:  FBMesaCreateContext (CreateContext)
    					radeon_context.c: radeonCreateContext
    		glfbext.c: glFBMakeCurrent
    			dri_mesa.c: driMesaBindContext (bindContext)
    					radeon_fbmesa.c: FBMesaCreateWindowBuffer
    				radeon_fbmesa.c: FBMesaMakeCurrent (MakeCurrent)
    					radeon_context.c: radeonMakeCurrent
    			glfbext.c: __glFBSetCurrentContext
    		radeon_driver.c: RADEONCloseScreen
    			radeon_dri.c: RADEONDRICloseScreen
    				dri.c: DRICloseScreen

    Important structures in FB DRI and where they are:

    glfbclient.h: GLFBcontext
    fbdrimain.h: FBDRI_Main

    Some important files:

    fbdri.c: These were previously client side requests in
    	lib/GL/dri/XF86dri.c, later received by a server side xf86dri.c and
    	then dispatched to pure DRI calls. These should be replaced by the
    	pure DRI calls.
    radeon_dri.c: Initializes the hardware.
    SDL_fbvideo.c: Initializes the function that initializes the hardware.
    glfbcmds.c, glfbext.c: Front end to the GL subsystem.  Functions
    usually start with "glFB"  Initializes the OpenGL specific stuff.
    dri_mesa.c: the front end to the front end of the GL subsystem.  Entry
    points used to initialize the system.  Functions usually start with
    radeon_fbmesa.c: Entry points initializing card specific portions of
    the DRI objects.  Usually start with "FBMesa"

    Freakout address

    Sourceforget project page