Linked by Hadrien Grasland on Tue 25th Jan 2011 15:29 UTC, submitted by sparklewind
BeOS & Derivatives A few months ago, a bounty for porting Gallium3D to Haiku was submitted. As the target sum of $2000 has been reached, what's needed now is a developer interested in doing the actual coding work. (Gallium3D is a cross-platform video driver API, on which an increasing number of open-source Linux drivers are based.)
Thread beginning with comment 459617
To read all comments associated with this story, please click here.
by werfu on Tue 25th Jan 2011 17:11 UTC
Member since:

I wonder if it requires to port DRI2/DRM. Also, could Gallium3D be ported over ReactOS or it wouldn't be compatible/usefull with the NT architecture?

Reply Score: 1

RE: ....
by Neolander on Tue 25th Jan 2011 17:14 in reply to "...."
Neolander Member since:

From the Gallium3D project's website ( ) :

"Gallium drivers have no OS-specific code (OS-specific code goes into the "winsys/screen" modules) so they're portable to Linux, Windows and other operating systems."

I have a hard time understanding how this can possibly work on something as performance-critical as a GPU driver, but keeping drivers cross-platform is one of their stated goal.

Edited 2011-01-25 17:16 UTC

Reply Parent Score: 3

RE[2]: ....
by Mark Williamson on Wed 26th Jan 2011 19:23 in reply to "RE: ...."
Mark Williamson Member since:

I have a hard time understanding how this can possibly work on something as performance-critical as a GPU driver, but keeping drivers cross-platform is one of their stated goal.

I'm not an expert on this but I have spent some time looking into Gallium3D (though that was mostly a few years back!).

AIUI, it's source compatibility not binary compatibility, so that's part of it. The other part is that to a certain degree the OS-specific stuff does:
a) set up a direct comms channel between the application and the graphics hardware, e.g. using shared memory. 3D rendering under X, for example, doesn't mostly (in principle) interact with the X server.
b) talk to the windowing system about where the rendering is / should be

Neither of these things are on the performance critical path, which is the communications protocol with the graphics driver. So in principle they don't really matter to graphics performance.

That still leaves the question of how they do 3D API stuff, though... Currently, OpenGL on Linux is built on Mesa, with a load of function calls for very high level operations which call lower-level operations, which call lower-level operations, etc. The default implemenations are all software. The individual graphics card reimplements what operations can be accelerated, according to its capability (better cards might accelerate more or higher-level ops).

For Gallium the idea is that modern graphics cards offer a certain range of functionality that can be hidden behind a low-level (as opposed to high-level OpenGL operations) function call interface. The driver just implements these low-level operations and doesn't need to worry about the API in use.

That suggests (to me - I am no expert) that the optimisation opportunities are at least going to be rather different compared to folding the driver code into the 3D API implemenation. Maybe this is going to be beneficial, maybe it will be awkward...

Reply Parent Score: 2

RE: ....
by deadwood on Tue 25th Jan 2011 20:14 in reply to "...."
deadwood Member since:

You don't need to port DRM, however Nouveau Gallium3D driver uses libdrm interface. You can implement your own libdrm-like module which will have all card init/control code and expose it through the libdrm interface. This however is a huge task and worth its own bounty. AROS port of Nouveau uses DRM with modifications kept to minimum so that we can relatively easy integrate upstream work.

Reply Parent Score: 2

RE[2]: ....
by Michael Oliveira on Tue 25th Jan 2011 20:54 in reply to "RE: ...."
Michael Oliveira Member since:

In fact, we already have a basic libdrm implementation

please take a look at

Reply Parent Score: 3