Bi Endian Support

From DirectFB

Jump to: navigation, search

What are Bi Endian Machines?

A Powermac with PCI/AGP uses a little endian framebuffer, while the host memory is big endian. This leads to some problems, which are not addressed in DirectFB yet.

What works? - The Endian Conversion Flags

Modern graphics cards have endian conversion flags, which can fix the incoming data from the host cpu/memory. For this purpose you can set 32-bit conversion or 16-bit conversion.

 When transferring a 32-bit word in 32-bit conversion mode, incoming byte order is changed from 1234 to 4321
 When transferring a 32-bit word in 16-bit conversion mode, incoming byte order is changed from 1234 to 2143

The linux framebuffer driver sets these flags accordingly when changing modes. This allows DirectFB to run on Big Endian Machines as if they had a Big Endian Framebuffer.

So, where is the problem, then?

When transferring 32bit surfaces from system to video memory, while running in a 16bit mode, the surfaces get crippled because:

 When transferring a 32-bit word in 16-bit conversion mode, incoming byte order is changed from 1234 to 2143


Michel Dänzer wrote:

EXA (the new X.Org acceleration architecture) currently approaches this problem something like this:

     * There are driver hooks that get called before and after CPU
       access to any pixmap stored in the framebuffer.
     * For cards that allow setting different swapping for different
       ranges of the framebuffer, these wrappers set up the ranges and
       swapping for the pixmaps.
     * Otherwise, if the pixmaps involved in the operation don't all
       require the same swapping, the wrapper that gets called before
       the access tells EXA to download the pixmaps into system RAM and
       do the CPU access there. This requires the driver to provide a
       way to download pixmaps that always works correctly of course.
Personal tools