Submitted by 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.)
Thanks for posting this, hopefully it’ll get some exposure now. Check out the other bouties too!
I might add, a similar port was completed for AROS, for $1082… (I already contacted this developer, and he was unable to work on the bounty, but said he’d offer advice/help)
http://www.power2people.org/projects/profile/33
Edited 2011-01-25 16:00 UTC
People who are good on working on video drivers are few and far between. I am quite happy with the performance of VESA graphics on Haiku, but it would be nice if there is just one way to perform 3d graphics across all video systems with speed of graphics the only thing affect by your graphics hardware.
Hope someone works on this bounty soon, I know it will not be me. I am getting headaches just making my CRAMDISK working under Haiku and it is less than 300 lines of code.
The video gods are a class of programmers onto themselves.
Edited 2011-01-25 16:12 UTC
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?
From the Gallium3D project’s website ( http://www.freedesktop.org/wiki/Software/gallium ) :
“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
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…
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.
In fact, we already have a basic libdrm implementation
please take a look at
http://dev.haiku-os.org/browser/haiku/branches/components/gallium3d
I’m actually somewhat surprised that nowhere in this news bit, or the bounty (or the comments attached to the bounty) is there mention of the existing work done to port Gallium3d to Haiku.
Was that project so little known that others in the community aren’t even aware that it was started, and significant progress was made on it already?
I think even the llvm softpipe was working already.
Edited 2011-01-25 22:03 UTC
Having a very small subset of source code in a big repo alone is insufficient to raise awareness; this is very easy to miss.
What may help make people more aware of such initiatives is if they had a home page with some of the basic info about the project (summary, goals, contact info, repo link, how to get involved, etc.), perhaps in the form of a microsite under the Haiku website.
Technically, the Gallium3D porting effort is an entire “development branch” of the Haiku codebase…but I see your point. Not much attention gets paid to those branches.
At the time that it was started, I remember some excitement on the commit list and/or development mailing list. I don’t seem to see any blog posts from Artur (the developer who was working on it), and it seems the project was “flying under the radar” so to speak.
I do recall some buzz about it on some news sites, however – but at this moment, you’re right – there’s no visibility. I just thought perhaps it would have been mentioned in relation to the bounty by now and was surprised that it hadn’t been
In any case, it looks like Karl added a blurb about it, so hopefully that will add some inspiration to any would-be takers, knowing that there is already some (significant?) progress made toward the port.
Yes.. softpipe was working (slowly) until a few releases ago.. but now will be necessary update the gallium branch…
Thanks to this news post, I just read about Gallium3D and how it aims to separate video card drivers from the operating system. What a cool concept!
I have a video card that’s supported by Haiku, but there sure are a lot of video cards that aren’t. I used to think it would be a huge task getting a large amount of video cards to work in Haiku. I’m sure it still is a huge task, but if Haiku can share video card drivers with Linux through Gallium3D, I think it would be a huge help.
However, your card does not yet have 3d acceleration in Haiku (because no cards do)…
Gallium3d could be integrated into our Mesa port such that it offers 3d hardware acceleration, and eventually, with enough card support, it could potentially be used for hardware 3d desktop/window compositing so that people can finally get all their fancy eye-candy effects such as transparency and window skewing affects that people seem to go crazy for.
3D acceleration is a noble goal, but can we at least get drivers that can properly handle HD resolutions and 2D acceleration?
I’m pretty sure Gallium3D should be able to handle that as well.
It doesn’t currently handle this on any other operating system (though, yes, theoretically it could if enough time was spent on it).
You weren’t specific about your particular needs – but I’ll assume you’re either using some recent video chip for which Haiku is still missing a driver (namely, a Radeon HD or nVidia G80 or newer chips), or simply uninformed.
Haiku does already have “simple 2D acceleration and modesetting” with support for HD screen resolutions. There’s a pretty decent range of chips supported as well – but there is currently zero 3d hardware acceleration support in Haiku (except perhaps for Rudolf’s experimental 3d nvidia driver, but it doesn’t work with Haiku’s opengl stack).
I am most certainly not uninformed. I noticed similar remarks on the mailing list back when the poll was done and so many people also requested modesetting drivers.
I suspect a large percentage of the poll-takers don’t even know if their hardware is supported by one of Haiku’s existing video drivers, and as a result were unable to make an informed choice on that particular question.
That should sound familiar… Why not accept that people actually knew what they were voting for and that I knew what I was talking about above?
No recent GPU that I’ve tried (various radeon and nvidia cards) supports HD modes or 2D acceleration. Thankfully the vesa driver is quite impressive, and the lack of 2D acceleration is not really a problem.
But 1280×1024 on an LCD that prefers 1680×1050 is just awful to look at.
Because I *seriously* doubt the > 1000 poll takers that I was referring to have tried Haiku on a large percentage of hardware. Out of the dozen or so machines I have tested Haiku on (mostly machines that are between 3 and 10 years old), the only one that springs to mind as having no accelerated video currently is my new Atom D510 with Intel’s N10 video. I do have a Radeon HD machine that I use for a media center which probably doesn’t work either, but I haven’t tested Haiku on it yet.
And, so, what do you propose is the solution to this problem of modern AMD/nvidia cards not having working 2d acceleration support? Clearly Haiku supports 2d acceleration and modesetting, and only the drivers are missing. Are you proposing that Haiku needs to implement the Linux graphics stack and port all the Linux drivers (including closed source, binary ones from nvidia)?
Note: This is different than the 3d acceleration problem where there is no current example of working 3d acceleration in Haiku. That is why I believe the Gallium3d port is arguably more important.
And while we’re quoting my emails, why not also include this bit:
Edited 2011-01-26 21:21 UTC
They don’t need to have tried it on a large percentage of hardware. They need to have tested it on their hardware and run into a problem with modesetting. I see no reason to doubt that’s the case.
No need to implement the binary ones. nouveau supports 2D acceleration, as does radeon. I can’t speak directly about nouveau, but there isn’t a radeon GPU (currently released) that doesn’t have 2D acceleration and modesetting in open source drivers on linux. And, no, I don’t suggest reimplementing the linux graphics stack. I suggest focusing on further development of the 2D drivers for Haiku that already exist to support more modern GPUs.
I would consider an example of working 3D acceleration in Haiku to be a low priority if users are going to have a hard time getting modesetting working on most of the GPUs you can currently buy off the shelf.
If the developers can’t keep up with 2D acceleration for GPUs on the market, what’s going to happen with the 3D support? In two years time, that 3D driver is going to support GPUs not easily available, and the 2D situation will be even worse than it is now.
In fact let’s take a look at the situation with radeon GPUs (since they are the ones I’m most familiar with). gallium3d currently supports 3D acceleration on all radeons from the r300 family and up. r300, r400, and r500 are supported via the r300g driver. r600 and higher (up to the Northern Islands / r900) are supported via the r600g driver. Which of those GPUs have 2D acceleration and modesetting in Haiku? r300 and r400. There may be a few places where you can still buy those GPUs, but by the time the gallium3d port is completed, finding one will be a challenge to even the best shopper.
BTW, that’s 5 generations of radeon GPUs that have no acceleration or modesetting. Some of those, obviously, may support HD resolutions if the video card itself is programmed with them, but that is not the case with the dozen AMD video card I’ve tested here.
Because, frankly, I don’t find the poll results of little value. I see no reason to take the results at anything but face value.
Edited 2011-01-26 23:15 UTC
Well, since you suggest a blanket “focus on development of 2d drivers”, I’ll challenge that this is not the best use of resources. Especially since Haiku developers are volunteers, unpaid, etc. They’re only likely to work on hardware drivers for chips that they own. And I *do* have a suggestion.
Back to my point that it would probably be better to identify the *important* chips to support rather than all of them, I propose that when a Haiku user runs into a card that doesn’t have native driver support, they should actually file an enhancement ticket in Trac: http://dev.haiku-os.org – Until that happens, we can’t possibly track what the actual users of Haiku are running into, hardware support wise.
I think Haiku should add ticket voting support to Haiku’s Trac so that other people who use the same hardware can vote that enhancement request up. Eventually we’ll *know* which cards are most important, and can focus our development efforts as such.
This would be a MUCH more manageable approach than putting out a vague poll about this topic and then hoping that the Haiku developers will magically just work on it. This would also allow funding of hardware purchases for developers to work on the most important chips first.
I do not disagree with anything you just said 🙂 Please understand that it’s not my intention to say the developers must work on more/better 2D drivers. I, personally, just feel it’s a better use of resources and a more logical goal than 3D acceleration for one or two models of GPUs.
I do not appear to have opened up a ticket for improved radeon support. My only previous ticket concerning video support, though, still seems to be open:
https://dev.haiku-os.org/ticket/3501
Maybe an enhancement ticket is still worth creating, though.
Adam
Indeed
And with that, this discussion reminded me that there’s a new patch for Intel N10 that I haven’t tested yet:
http://dev.haiku-os.org/ticket/6202
I’m sure, if we find somebody willing to port Galium3D, then I’m sure that the bounty will rise even more.
But it requires abandoning conventional wisdom. It would never be as fast as an actual video card, natively supported with a proper driver, but it would likely, be much faster than what we have currently.
There was work done on the new OS kernel years ago to support vesa 3.0 which allows for alot more modesetting power. Maybe the haiku devs could investigate such a feature to update the existing vesa 2.0 driver with a more powerful vesa 3.0. I know the source code it still in the newos trunk I looked at it just a few days ago.I just don’t have the needed deep system knowledge to get it working.